Clean Code – nicht nur richtig, sondern gut entwickeln

Robert C. Martin ist einigen vielleicht als Initiator des Manifests für Agile Softwareentwicklung Anfang der 2000er bekannt. Außerdem ist er einer der führenden Vertreter des Software Craftsmanships: Er sieht Softwareentwicklung als Handwerkskunst, die den gleichen Qualitäts- und Moralstandards unterliegen sollte wie andere Ingenieursberufe. Wer jetzt schon neugierig geworden ist, sollte einfach mal nach „Uncle Bob“ suchen – wie Robert C. Martin in der Szene auch genannt wird. Dabei stoßt ihr sicherlich auf viele spannende, lebhafte und mit Witz erzählte Vorträge, die mich selbst immer wieder über Stunden fesseln können.

In seinem Buch „Clean Code“ erklärt „Uncle Bob“, was die Gefahren von schlechtem Code sind und warum es für Unternehmen ein großes Risiko darstellt, unsauberen Code zu pflegen. Denn auf lange Sicht bleibt die Entwicklung eines Unternehmens nur schnell und agil, wenn der Code sauber bleibt. Deswegen lohnt es sich, Code zu refactoren, auch wenn das vielleicht etwas länger dauert. Später wird es sich aber garrantiert auszahlen.

In den folgenden Kapiteln werden verschiedene Aspekte von sauberem Code betrachtet. Im Laufe des Buchs arbeitet sich „Uncle Bob“ von kleinen Strukturen zu großen Systemen. Los geht’s mit einer Betrachtung, was bedeutungsvolle Namen sind und wie man gute Namen für Variablen, Methoden und Klassen findet. Das nächste Kapitel beschäftigt sich mit Funktionen, ihren Parametern und Rückgabewerten und was dies alles mit dem Erzählen einer Geschichte zu tun hat. Im Folgenden geht es um Objekte, Datenstrukturen und Klassen sowie um die Frage, warum es wichtig ist, dass eine Klasse nur eine einzige Aufgabe erfüllt. Gegen Ende gibt es dann noch einen Überblick über komplexere Systeme – hier wird erklärt, wie die Komponenten und Klassen miteinander interagieren sollten.

Zwischendurch gibt es immer wieder Ausflüge in andere Bereiche wie Kommentare, Formatierung, Unit Tests, Fehlerbehandlung und Nebenläufigkeit. „Uncle Bob“ zeigt die aus seiner Sicht wenigen guten Gründe für Kommentare. Darüber hinaus erläutert er, warum viele häufig gesehene Kommentare nicht nötig – oder sogar hinderlich – sind. Eine Aussage, die eine meiner Professorinnen auch immer unterstützt hat, die ich jetzt aber erst so richtig verstanden habe.

Im letzten Drittel des Buchs gibt es viel Code zu sehen. Hier erklärt „Uncle Bob“ die Methoden des Refactorings und zeigt anhand von praktischen Beispielen, wie er selbst vorgeht. Dabei erläutert er sehr gut, warum er bestimmte Dinge auf die eine oder andere Art umsetzt. Beim Code im Buch handelt es sich um Java, aber auch für Nicht-Java-Entwickler ist dies gut nachvollziehbar; ein Verständnis von Objektorientierung ist zwar hilfreich, aber meiner Meinung nach nicht zwingend notwendig.

Bisher bin ich hier nur recht knapp auf die einzelnen Kapitel eingegangen, was daran liegt, dass es in den kommenden Wochen noch ausführlichere Beiträge zu einigen Kapiteln geben wird. Ich freue mich schon darauf, mit euch über die Themen zu diskutieren. Wer jetzt schon mehr wissen will, sollte sich das Buch kaufen.

Trotz seiner Länge und Komplexität – es ist kein Roman, den man einfach so nebenbei liest, sondern ein Arbeitsbuch – habe ich es in wenigen Wochen förmlich aufgesogen. Ich denke, jeder Entwickler, der mehr als ein Hello-World-Programm entwickeln möchte, sollte sich mit Codequalität beschäftigen. Dieses Buch stellt einen guten Einstieg für alle dar – von Auszubildenden bis hin zu Entwicklern mit 20 Jahren Berufserfahrung.