Björn Geisemeyer

Björn Geisemeyer

Clean Code Developer Artikel

dotnetpro clean code developer artikel

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

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

Unsere Seminare

course
Clean Code Developer Basics

Prinzipien und Tests – Das Seminar wendet sich an Softwareentwickler, die gerade beginnen, sich mit dem Thema Softwarequalität auseinanderzusetzen. Es werden die wichtigsten Prinzipien und Praktiken der Clean Code Developer Initiative vermittelt.

zum Seminar »
course
Clean Code Developer Advanced

Mit Flow Design von den Anforderungen zum Clean Code – Lernen Sie mit Flow Design einen Softwareentwicklungsprozess kennen, der Sie flüssig von den Anforderungen zum Clean Code führt.

zum Seminar »
course
Clean Code Developer Trainer

Seminare als Trainer durchführen – Dieses Seminar wendet sich an Softwareentwickler, die ihr Wissen über die Clean Code Developer Prinzipien und Praktiken bzw. über Flow Design als Trainer an andere weitergeben möchten.

zum Seminar »
course
Clean Code Developer CoWorking

Online CoWorking inkl. Coaching –
Wir werden häufig gefragt, was man als Entwickler tun könne, um kontinuierlich dran zu bleiben am Thema Clean Code Developer. Unsere Antwort: Treffen Sie sich regelmäßig wöchentlich online mit anderen Clean Code Developern.

zum Seminar »

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht.