Software wie ein Buch – Clean Code in der Architektur 

Onkel Bob beschreibt Clean Code in seinem gleichnamigen Buch als Metapher der Zeitung. Da Software häufig komplexer als eine Zeitung ist, denken wir, dass die Metapher des Buches besser geeignet ist. In diesem Blog beschreiben wir warum. 

Inhaltsverzeichnis 

Wenn wir in eine bestehende Software uns neu einarbeiten, müssen wir uns als erstes einen Überblick verschaffen. Als erstes sollte einen interessieren, was die Software für Features und Möglichkeiten hat. Ein guter Anlaufpunkt hierfür ist die package oder Ordnerstruktur der Anwendung. 

Wenn wir nun Services, Entities und Controller sehen, wissen wir immer noch nicht, was unsere Software kann. Viel besser ist es, wenn die Packages nicht per Layer, sondern per Feature strukturiert sind. Wenn wir nun article, order, seach und user sehen, wissen wir, dass wir vermutlich Artikel beauftragen können. 

Überschriften

In der Abbildung des Beispielprojektes sehen wir vier Klassen. Erwartet wäre hier noch ein OrderService. Diese Entität + Service-Klassen sind für CRUD-Operatoren sehr sinnvoll und erwartbar. Sofern die Businesslogik komplizierter ist, sollten diese Logiken in eigene Klassen ausgelagert werden. Somit habe ich im ersten Überblick das Wissen, dass die Berechnung von Versandkosten komplexer zu sein scheint. Hier ist Fingerspitzengefühl gefragt, denn wenn jede kleine Funktionalität in einer eigenen Klasse wäre, würde man den Überblick verlieren. Hier verhält es sich genauso wie ein Buch. Im Inhaltsverzeichnis möchte ich eine Übersicht der Unterüberschriften, die wichtig sind. 

Aus meiner Erfahrung sollten EntwicklerInnen aber eher motiviert werden, neue Klassen zu erstellen, da dieses Handwerk häufig vergessen wird. Die neu erzeugten Klassen müssen auch nicht Service heißen. Eigentlich ist Service genauso ein leeres Wort wie Manager oder Helper, nur warum ist es nicht so verpönt? 

Die Absätze 

Sofern wir die interessante Klasse gefunden haben, werden wir diesen Teil des Buches lesen. Am besten erkennen wir an der Struktur schon, dass sich der Inhalt in gewisse Teile aufteilt. Evtl. können einige uninteressante übersprungen werden und man liest ab den nächsten Absatz weiter. 

Genauso verhält es sich mit Methoden, ich möchte schnell zu der für mich relevanten Information browsen können und alles nicht Interessante ausblenden. Anders als bei Klassen, bei dem es zu kleinen Klassen geben kann, gibt es keine zu kleinen Methoden. Es lohnt sich auch Einzeiler in Methoden auszulagern, wenn sie dadurch wiederverwendet werden können, durch einen Methodennamen einen Mehrwert bringen oder es dem Integration Operation Segregation Principle dient. 

Der Text 

Sofern man die Methode oder den gewünschten Absatz gefunden hat, liest man den Text. Der Quellcode sollte so lesbar sein, dass ich den möglichst fließend lesen kann und Störwörter vermieden werden.  

Gleichzeitig sollte der Text so kurz und einfach sein, dass die Logik einfach verständlich in den Kopf gelangt. 

Rückentext 

Ein Teil des Buches wurde noch nicht beschrieben, der Rückentext. Dieser gibt einen textlichen Überblick über den Inhalt des Buches. Sofern die Software “eh” angefasst werden muss, ist dieser Überblick nicht relevant.  

Sofern ich eine Wahl habe, z.B. Support eines OpenSource Frameworks, sollte dieser Rückentext gut beschrieben sein. Diesen Überblick erhalte ich auf, z.B. github wenn ich ein Repo öffne. Hier wird die Readme geparst, also könnte man sagen, dass eine gute Readme einen guten Rückentext entspricht. 

Shift-Up Prinzip 

Anhand dieser Metapher können wir erkennen, dass man sich von oben nach unten in eine Software einarbeitet oder sich dadurch navigiert. Das zeigt aber auch auf, dass die Wichtigkeit der klaren und korrekten Beschreibung von oben nach unten geschieht. Die Klasse muss sehr präzise beschrieben werden, damit ich zielgenau dorthin navigieren kann.  

Häufig sehen wir Softwaresysteme, wo sehr präzise Variablennamen beschrieben werden. Die Methoden sind aber sehr lang und die Klasse heißt UtilManager. Dies ist dann nicht Clean Code. Man ist nicht in der Lage schnell und effektiv zur gewünschten Sourcestelle zu navigieren. Wenn eine Methode 3 Zeilen lang ist, ist es fast egal, wie die Variable heißt. Die Betonung liegt auf fast. Natürlich ist gute Benennung trotzdem wichtig. Daher die Empfehlung, die korrekte Benamung nach oben zu shiften.