Buch-Rezension zu “Clean Code”

“Clean Code: A Handbook of Agile Software Craftsmanship” von Robert C. Martin erschien 2008 bei Prentice Hall. Auch wenn die Beispiele in Java sind, ist das Buch jedem Entwickler zu empfehlen. Abgesehen von einigen Kleinigkeiten betrifft die Problematik (mindestens teilweise) auch alle anderen Programmiersprachen.

Das Buch beginnt mit der Erklärung, wieso sauberer Code notwendig ist. Auf längere Sicht ist der Aufwand zur Wartung von verrottendem Code schlicht unbezahlbar. Wenn selbst die kleinste Änderung grossen Aufwand verursacht, bremst es die Entwicklung und die Kosten laufen vollends aus dem Ruder – von den Terminen ganz zu schweigen.

Wer ist nun Schuld an schlechtem Code? Martin sagt unmissverständlich: die Entwickler. Nicht der Teamleiter, nicht das Marketing und nicht der Kunde, sondern die Entwickler. Sie schreiben den Code, also ist es ihre Aufgabe ihn sauber zu halten. Es muss in ihrem Interesse sein, den Code sauber zu halten. Wer schlechten Code schreib nur um die Deadline zu halten wird diese erst recht verpassen.

Martin zeigt in dem Buch auf, wie man zu sauberem Code kommen kann. Er stellt aber auch klar, dass sein Ansatz nicht der alleinig selig machende ist. Andere Ansätze soll man sich ebenfalls anschauen und hinterfragen – genau wie seine.

Das Buch widmet sich dem ganzen Spektrum der Entwicklung und zeigt immer, wie man an der entsprechenden Stelle den Code verbessern kann. Die weiteren Themen sind:

• Sinnvolle Namen
• Funktionen
• Kommentare
• Formatierung des Codes
• Objekte und Datenstrukturen
• Fehlerbehandlung
• Grenzen
• Unit Tests
• Klassen
• Systeme
• Emergenz
• Nebenläufigkeit
• Schrittweise Verfeinerung

 
Fazit
Um es vorweg zu nehmen: Clean Code bringt keine neuen und revolutionäre Ideen. (Ausser man sieht das konsequente Einfordern von Qualität durch den Entwickler als Revolutionär an) Alles was behandelt wird kann man auch in anderen Büchern finden. Neu ist allerdings, dass alles zusammen in einem Buch vorkommt. Dies macht für mich den Wert dieses Buches aus. Sollte die Zeit für Weiterbildung so kurz sein, dass man nur ein Buch pro Jahr lesen kann, ist Clean Code eine sehr gute Wahl. Neben der Themenvielfalt hilft es einem produktiver zu werden und besseren Code zu schreiben.

Wie es Martin aber auch selber schreibt: man muss die Vorschläge als Vorschlag sehen und nicht als einzig richtigen Weg. Das Agil im Titel hätte man weglassen können. Die Handwerkskunst ist nicht auf die agilen Vorgehensmodelle limitiert und schreckt manchen Leser wohl eher ab.

 
Zum Weiterlesen
Wem die Ideen von Martin gefallen, sollte sich die Initiative Clean Code Developer anschauen.

 
Zum Buch
Clean Code: A Handbook of Agile Software Craftsmanship von Robert C. Martin, 2008 Prentice Hall International, ISBN 978-0-13-235088-4, 464 Seiten

Braucht es Bugtracking noch?

Ilker Cetinkaya bloggte zu dem Thema und kam zum Schluss, dass Bugtracking heutzutage unnötig sind. „Aber sicher braucht es dies noch!“ war mein erster Gedanke. Ich las darauf hin nochmals seinen Beitrag und dachte ein wenig länger über seine Argumente nach.

Heutige Projekte meint bei ihm Projekte, die ein agiles Vorgehensmodell haben, TDD und CI in vollem Umfang nutzen und generell gemäss Clean Code Developer die Qualität hochhalten.
Bugs werden so weit wie möglich durch Unit Tests verhindert und wenn ein Bug durchkommt, wird dessen Behebung mit einer dem Kundennutzen entsprechenden Priorität versehen. Entweder wird dieser gleich behoben oder verworfen, falls er nicht wichtig ist.

Außerdem: Gefühlt implementiert nahezu jeder, der was auf sich hält seine Software mit agilen Methoden und Praktiken. Scrum und XP sind schon längst angekommen; und mit TDD und Clean Code wir bewegen uns auf einem hohen Niveau, oder nicht?

Das wäre schön. Das was „jeder“ macht wird zwar oft agil genannt, doch ist es das wirklich? Oder ist es nicht eher ein Etikettenschwindel?

Bei mir läuten die Alarmglocken. Ich höre schon die Leute sagen, dass man als agiles Projekt generell kein Bugtracking braucht. Genau so wenig wie Dokumentation. Oder eine Planung. Doch nur weil man die Dokumentation weglässt, ist man noch lange nicht agil!

Bei länger laufenden Projekten hat die Nachvollziehbarkeit eine nicht zu unterschätzende Bedeutung. Die Entwickler-Teams ändern gleich wie die Kundenvertreter, neue Leute kommen und gehen. Ein Bugtracking hilft da schon abgeklärte Probleme nicht ständig wieder von vorne behandeln zu müssen. Die Erarbeitung von Workarounds kann da vielleicht ebenfalls abgelegt werden, gleich wie die Anleitung zur Reproduktion des Bugs oder einer Begründung, wieso man auf die Fehlerbehebung verzichtet.
Das macht natürlich auch nur dann sinn, wenn man die offenen Bugs abarbeitet. Einfach mal aufnehmen und dann jahrelang nicht bearbeiten kann nicht der Sinn der Sache sein. Das liegt aber nicht per se am Bugtracking, sondern wie man damit arbeitet.

Bugtracking lässt sich mittels Software vereinfachen. Wie man Bugs (und Feature Requests) aufnimmt und bis zur Erledigung ablegt, muss zum Projekt passen. Bugtracker sind da eine Möglichkeit, die bei der Verfolgung der Bugs helfen. Aber je nach Projektgrösse genügt auch eine Textdatei oder ein Wiki.
Ein halbwegs brauchbarer Bugtracker sollte einem auch beim Auswerten der Bugs helfen. Kann man auf Klassen- oder zumindest auf Komponentenebene die Bugs kategorisieren und auswerten, sieht man wo man bessere Tests schreiben muss.
Zu wissen wo die Qualität nicht den Anforderungen entspricht ist auch bei Legacy-Code sehr hilfreich. Dort fehlt es ja meistens an Unit Tests. Kann man mit gezielten Verbesserungen genau dort ansetzen, hat am Ende auch der Kunde etwas davon.

Für mich ist Bugtracking daher wichtig. Wie bei allem stellt sich auch da die Frage, wie viel Aufwand man betreiben will. Es ist sicher nicht der Sinn der Sache, die ganze Zeit nur Bugs zu erfassen und dann keine Zeit für deren Behebung zu haben. Wie man die Kunden informiert und wie man die Bugs abarbeitet liegt nicht per se am Bugtracking, sondern wie man dies definiert und lebt.

In der Zwischenzeit fand ich eine Antwort von Golo Roden zum Post von Ilker Cetinkaya. In seinem Blogpost gibt es weitere gute Aspekte zur Begründung von Bugtracking.