Was braucht es, damit wir «sauberen» Code haben? Das Buch «Clean Code» von Robert C. Martin gibt Aufschluss darüber. Ein Muss für jeden Software-Entwickler!
Code zu schreiben, der funktioniert und eine Spezifikation erfüllt, ist in der Regel nicht ganz einfach umzusetzen. Code zu schreiben, der zusätzlich noch erweiterbar, wartbar und lesbar sein soll, macht die Aufgabe nicht einfacher. Hier setzt das Buch Clean Code von Robert C. Martin an: Clean Code soll das Fundament in einem Software Entwickler Team sein. Clean Code soll das gemeinsame Verständnis von Software Qualität innerhalb eines Unternehmens sein.
Dieser Blog gibt einen kurzen Einblick in das Buch und zeigt einige Konzepte von Clean Code auf. Ich möchte damit Software Entwickler und -Entwicklerinnen ermuntern, das Buch von Robert Martin zu lesen oder mindestens in Zukunft den eigenen Code kritisch zu betrachten.
Kommentare
Kommentare helfen dem Entwickler zu verstehen, was eine Methode, eine Verzweigung oder eine Klasse macht oder wie diese zu verwenden ist. Vielfach sind Kommentare veraltet und machen das Refactoring der Klasse nicht gleichermassen mit. Auch sind Kommentare oft redundant zu dem Methodennamen. Solche Kommentare sind überflüssig und sollen gelöscht oder noch besser mit einem sinnvollen Kommentar ersetzt werden. Ein Kommentar soll einen Mehrwert bieten und nicht gewisse Metriken erfüllen, die dem Managemenet zeigen, dass zum Beispiel 95% der öffentlichen Methoden mit einem Kommentar versehen sind.
Wird im Code ein gewisser Abschnitt mit «synchronized» gegen nebenläufigen Zugriff abgesichert, soll die Motivation und der Grund hierzu immer kommentiert werden. Multithreading macht eine Klasse deutlich komplexer; sinnvoller Kommentar soll diese Komplexität entschärfen oder zumindest verständlich machen.
Funktionen
Funktionen sollen – ebenso wie Variablen – aussagekräftige Namen haben. Der Entwickler muss bereits ohne Kommentar erkennen können, was die Methode macht. Keine Scheu vor zu langen Methoden Namen. Lieber einen etwas längeren Namen, der die Methode beschreibt, als einen kurzen Namen, der nichts über diese aussagt. Der Entwickler soll auch Mut zu Veränderungen an den Tag legen. Wird etwas an der Methode geändert, so dass der Methodennamen nicht mehr passend erscheint, soll dieser auch gleich angepasst werden. Mit den heutigen Entwicklungsumgebungen ist dies kein Problem mehr und kann im kompletten Source Code unkompliziert geändert werden.
Die Anzahl der Funktionsargumente ist immer wieder Gegenstand heftiger Diskussionen. Generell darf sicherlich gesagt werden, dass mehr als drei Argumente die Lesbarkeit und Verständlichkeit der Methode drastisch verschlechtern. Ein Nebeneffekt von vielen Argumenten in einer Methoden-Signatur ist die abnehmende Testbarkeit der Methode.
Boolsche Ausdrücke, sogenannte Flag Argumente, sind generell unschön und deuten darauf hin, dass die Methode wohl zwei verschiedene Sachen macht. Dies sollte ebenfalls vermieden werden. Die Lösung hierfür ist einfach – das boolsche Argument wird aus der Signatur entfernt und es entstehen zwei neue Methoden. Bei anderen Funktionen, die drei oder mehr Argumente in der Signatur haben, muss überlegt werden, ob die Methode nicht in zwei oder gar drei Methoden aufgeteilt werden kann oder ob aus den Input-Variablen allenfalls eine neue Klasse erstellt werden soll. Letzteres macht nur Sinn, wenn die Fachlichkeit dafür gegeben ist. Kürzere Methoden bieten auch den Vorteil, dass sie einfacher getestet werden können.
Tests
Test Driven Design (TDD) sollte in jedem Software produzierenden Unternehmen ein bekannter Begriff sein. Tests sind Teil der Dokumentation und dienen als Absicherung für den Entwickler und das Unternehmen, dass ein Refactoring erfolgreich war. Eine gute Testabdeckung ermutigt den Entwickler auch, den oft fremden Source Code zu verbessern. Was in einem ersten Schritt und unter kurzfristiger Betrachtung als Mehraufwand zu Buche schlägt, wird bei Change Requests oder Erweiterungen oft zum letzten Rettungsanker. Unit Tests sollen mit dem Projekt wachsen, sie sollen ebenso wie der Code gewartet werden. Meldet der Kunde einen Fehler in der Software, wird dieser zuerst in einem Unit Test nachgestellt. Erst danach darf sich der Entwickler mit dem Beheben des Tests befassen. Tests müssen ebenso wie der produktive Code sinnvolle Kommentare haben und ebenso lesbar wie der zu testende Code sein. Unit Tests sind nur nützlich, wenn diese regelmässig ausgeführt werden. Der Entwickler muss, bevor er den Code
eincheckt, alle Tests lokal ausführen. Erst wenn alle Tests erfolgreich waren, darf eingecheckt werden.
Software Entwickler sind Autoren
Die Annotation @author ist nicht grundlos Bestandteil der Klassendokumentation. Software Entwickler sind Autoren und das müssen wir uns vermehrt zu Herzen nehmen. Früher oder später wird unser Source Code von jemand anderem gelesen. Auch wir haben den Anspruch, dass das, was wir lesen, leicht lesbar und – was noch wichtiger ist – verständlich ist.
Fazit
Clean Code ist ein wunderbares Buch mit vielen einfachen und einleuchtenden Beispielen, wie mit einfachen Mitteln und Ansätzen Code effizienter und langlebiger wird. Anhand von vielen Code Beispielen wird aufgezeigt wie «schlechter» Code in «guten» Code umgeschrieben werden kann; dies oftmals mit verblüffenden Resultaten. Clean Code ist einerseits eine Pflichtlektüre für jeden ernsthaften Software Entwickler und andererseits ein Buch, das in keiner Software Firma fehlen darf. Interessant ist zudem die Clean Code Bewegung aus Deutschland mitzuverfolgen.