In diesem Artikel behandeln wir gutes API-Design. Wie können wir den Entwickler an die Hand nehmen und den Einstieg mit einer Bibliothek vereinfachen? Dieser Artikel liefert einige Aspekte.
Vorab: Dieser Artikel erhebt keinen Anspruch auf Vollständigkeit. Aufgrund meiner aktuellen Erfahrung mit einem NuGet-package möchte ich vor allem anregen, den Konsumenten einer API bzw. Softwarebibliothek zu unterstützen. Es gibt nichts frustrierenderes als mehrere Stunden mit einer Bibliothek beschäftigt zu sein, um irgendwie zu erfahren, dass man es anders machen muss.
Ich habe in einem vorherigen Beitrag über Code-Guidelines geschrieben. Guidelines sind super, doch was machen wir, wenn wir keine einheitliche Sprache sprechen?
Was ist passiert? Es ging um die Modularisierung von einem Projekt und ob es bestimmte Dienste gibt, welche Informationen für diese Module (bzw. die Endanwendung) bereitstellen. Manche dieser Module wurden als Service bezeichnet. Ein Service für Benutzerverwaltung, ein Service zur Berichterstellung, ein Service für Dateiaustausch, ein Service zur Verwaltung der Konfiguration.
Zu vielen Projekten gibt es Changelogs, welche die Änderungen von Version zu Version dokumentieren. Doch wie schreiben wir einen Changelog und was sollte enthalten sein? Diese Fragen wird dieser Artikel behandeln.
Sinn und Zweck Wozu brauchen wir Changelogs? Bei sehr kleinen Projekten macht es vielleicht wenig Sinn, einen Changelog zu pflegen. Handelt es sich um ein größeres Projekt (eine Anwendung oder große Bibliothek) ist es schön, neue Funktionen und Änderungen schnell zu erfassen.
Ich bin über folgenden Artikel von Joel Spolsky gestoßen: Making Wrong Code Look Wrong . Der Artikel ist schon einige Jahre alt aber, wie ich finde, immernoch aktuell.
Wir Entwickler lieben es, lesbaren Code zu schreiben und immer positiv zu bleiben 😉
Verschiedene Kriterien wie Wartbarkeit, Erweiterbarkeit usw. sind bekannt. Leider kommt es manchmal dazu, dass wir unsauberen Code schreiben. Vor allem, wenn es sich ein Provisorium zur einmaligen Ausführung handelt (welche erfahrungsgemäß am längsten im Einsatz sind).
Damit meine ich nicht nur die persönliche Einstellung zu bestimmten Dingen. Auch in der Softwareentwicklung kann eine positive Bezeichnung der Variablen erheblich helfen und die Wartung von Code vereinfachen.
Schauen wir uns zur Veranschaulichung folgendes Beispiel an (in leicht abgewandelter Form schon mehrmals so gesehen):
if (!fooBar.IsNotEmpty){ // .. code .. } Worin besteht hier genau das Problem? Der Code ist ja eindeutig. Wenn „IsNotEmpty“ nicht wahr ist, wird der Code ausgeführt.
