Frei verfügbare Clean Code Developer Artikel aus der dotnetpro
Die dotnetpro, namentlich der Chefredakteur Tilman Börner, hat die ersten vier Artikel der Clean Code Serie frei zugänglich gemacht. Im folgenden ist kurz beschrieben, worum es jeweils geht. Ferner findest Du jeweils einen Link zu den Artikeln.
Im Prinzip steckt der Teufel im Detail
Die Clean Code Developer Prinzipien helfen uns, Strukturen im Code aufzubauen und zu erhalten. Jedes hat einen eigenen Hintergrund, eine eigene Botschaft und drückt sich im Code auf eine eigene Art aus. Zugegeben, bei 45 Prinzipien und Praktiken kann man schon auf den Gedanken kommen, dass sich inhaltlich Überschneidungen ergeben und einige womöglich austauschbar sind.
Nehmen wir die beiden Prinzipien Single Responsibility Principle (SRP) und Integration Operation Segregation Principle (IOSP). Inhaltlich kann man argumentieren, dass das IOSP eine Spezialisierung des SRP ist. Die Trennung von Integration und Operation bedeutet, eine Trennung der Verantwortlichkeiten. Operationen dürfen nur Details beinhalten, also Ausdrücke, Framework- und Runtime-APIs. Integrationen dagegen haben die Verantwortung, Methoden der eigenen Domäne aufzurufen. Daraus kann man folgern, es ginge beim IOSP um das gleiche, was das SRP ausdrückt. Schaut man genauer hin, stellt man fest, dass es so nicht ist. Denn das IOSP trifft keine Aussage darüber, dass eine Operation nur eine Verantwortlichkeit haben darf. Das muss es auch nicht, denn da greift das SRP. Umgekehrt geht aus dem SRP nicht explizit hervor, dass die Trennung von Integration und Operation eine Trennung nach Verantwortlichkeiten ist. Diese Aussage trifft erst das IOSP.
Aus dieser Betrachtung kann geschlossen werden, dass die Prinzipien sich tatsächlich inhaltlich überschneiden. Daraus ergibt sich nicht Austauschbarkeit, sondern gegenseitige Ergänzung. Das SRP kann man beachten ohne das IOSP zu berücksichtigen und vice versa. Allein angewendet, sind beide Prinzipien ein Fortschritt für die Codequalität. Gemeinsam werden sie ein unschlagbares Team.
Ein weiteres Beispiel zu dieser Thematik hat Stefan Lieser im dotnetpro Artikel über KISS und YAGNI verfasst.
https://www.dotnetpro.de/planung/clean-code/kiss-yagni-2730355.html
Refactoring ist gut, Kontrolle ist besser
Obacht, auch bei der konsequenten Anwendung der Prinzipien gibt es Herausforderungen. Prinzipien überschneiden sich. Werden alle beachtet, ergänzen sie sich. Werden sie es nicht, kann daraus folgen, dass ein Prinzip verfolgt und dadurch unmittelbar ein anderes Prinzip verletzt wird. Ein kleines abstraktes Beispiel: In einem Refactoring findet sich eine Funktion mit Integrationscode und Operationscode. Wir wenden das IOSP an und trennen Integration von Operation. Entstandene Integrationen erfüllen implizit das SRP. Operationen hingegen können mehr als eine Aufgabe erfüllen und das SRP verletzen. Das beeinträchtigt die Wandelbarkeit. Der Code wird zwangsweise schwerer lesbar und ein neues Feature einzubauen wird komplizierter. Ebenso haben wir einen negativen Einfluss auf die Korrektheit. Eine Operation, die mehr als eine Aufgabe erfüllt, lässt sich in der Regel nicht gut testen. Die Tests werden meist unnötig komplex. Kontrolliere also bei Refactorings nach bestimmten Prinzipien auch die Einhaltung der übrigen.
Eine konkretes Beispiel zu dieser Herausforderung findest Du anschaulich und weit ausführlicher im dotnetpro Artikel „Don’t repeat yourself! – Und wenn doch?“.
https://www.dotnetpro.de/planung/clean-code/don-t-repeat-yourself-2701511.html
Clean Code Trainings
Geschlossene Firmenkurse
Wir führen alle Seminare als geschlossene Firmenkurse für Sie durch.
Bei Interesse oder Fragen kontaktieren Sie uns gerne.
Apropos komplexe Tests und wie das IOSP hilft, sie zu verhindern
Betrachten wir das Thema Abhängigkeiten, die wohl größte Herausforderung der Softwareentwicklung in Bezug auf Wandelbarkeit und Korrektheit. Mangelnde Planung und unstrukturierte Implementierung führen häufig zu ebenso unstrukturierten Abhängigkeiten im Quelltext. Diese werden gerne deutlich, wenn man versucht Tests zu schreiben. Wer kennt nicht wenigstens eine Methode, die nur mit Hilfe von Dependency Injection und Mocks zu testen war? Immerhin, wird das DIP angewendet, lässt sich die Abhängigkeit von außen mitgeben und für den Testfall durch eine Attrappe ersetzen. Das ist doch schon gut, oder?
Ja, denn die Testbarkeit wird erreicht. Und doch wirkt es zu Recht weit sperriger als notwendig. Denn viele Methoden können auch einfach ganz ohne DI auskommen.
Die Strategie dazu heißt IOSP und Stefan erläutert sie in diesem Artikel. Unbedingt lesen!
https://www.dotnetpro.de/planung/clean-code/dip-iosp-2718576.html
Blackbox vs. Whitebox
Das IOSP führt zu guter Testbarkeit. Integrationsmethoden können einfach durch Integrationstests getestet werden, Operationen einfach mit Unittests. Durch eine gute Kombination aus beiden bekommen wir eine optimale Testabdeckung. An dieser Stelle setzt in Seminaren zumeist die Debatte über Blackbox- versus Whitebox-Tests ein. Häufig entstehen Fragen wie „Sind Operationen nicht privat?“, „Wie kann ich die denn testen?“ oder „Sollte man nicht ausschließlich public Methoden testen?“.
Das Thema Black-box vs. White-box Tests hat Stefan hier im Blog bereits behandelt. Antworten auf die Fragen und noch mehr findest Du ferner in folgendem Artikel von Stefan in der dotnetpro. Viel Spaß beim Lesen.
https://www.dotnetpro.de/planung/clean-code/schwarz-weiss-liegt-menge-grau-2711296.html
German 
English