Teil 1 war der angenehme Part. Wer hier stehen bleibt, für den ist in der Tat Clean Code so weit weg wie die auf dem Buchtitel des englischen Exemplars abgedruckte Sombrero Galaxie. In den folgenden 3 Kapiteln dieses Teils geht es darum, wie solch sauberer Code entsteht. Hier wird es erst interessant, kommt doch hier die Praxis. Martin sagt, dass sauberer Code durch kontinuierliche Verbesserung erreicht wird. Das erste Programm ist nur der erste Entwurf. Wenn das Programm funktioniert, ist nicht Schluß, sondern es wird so lange gefeilt, bis der Code aufgeräumt ist. Um nicht sofort auf die Nase zu fallen zeigt Martin im ersten Beispiel zuerst das Endergebnis zahlreicher Refaktorisierungen und erst danach den Erstentwurf. Wie er betont, wollte er von Anfang an ein vernünftig organisiertes Programm schreiben. Aber es ist ihm nicht gelungen. Warum sollte uns das? Er stellt dar, wie sich die Unordnung auf natürliche Weise einschlich. Mit jedem Feature wurde das Programm chaotischer. Hier kam die Bremse. Da das Ganze immerhin eine Einheit war, konnte er für die vorhandene Funktionalität Tests schreiben, die ihm zuverlässiges Feedback lieferten, ob alles funktionierte. Huch? Hatte er denn nicht mit Tests angefangen. Test Driven Development ???
Für meinen Geschmack waren die Codefragmente viel zu lang. Aber ich bin der Meinung, man muss nicht jede Codezeile verstehen. Die Einschlägige Lektüre ist Refactoring von Martin Fowler.
Der erste Teil des Buches besteht aus Prinzipien, Mustern und Praktiken, die sich in sauberem Code wieder finden. Und dies ist der weniger harte Teil. Er ist sehr schön zu lesen. Es fängt damit an, wie man Namen verwenden soll. Das Bild von der Familie mit den Kindern spricht Bände. Und zwar sollen Namen mit Sorgfalt und Bedeutung vergeben werden.
Funktionen sollten unbedingt klein sein und eine Sache tun. Die Inhalte der Funktion sollten sich auf dem gleichen Abstraktionsniveau befinden. Der Funktion sollten so wenig wie möglich Argumente übergeben werden.
Schön ist der Vergleich von einem Stück Programmcode mit einem Zeitungsartikel. Während zu oberst die wichtigsten Dinge stehen, geht der Artikel mehr und mehr ins Detail. So sollte es mit Funktionen, die in einer Datei aufgelistet sind, auch sein. Ein anderer Vergleich ist der Quelltext mit einer Geschichte. Während die Klassen die Nomen sind, stellen Funktion die Verben dar. Wenn Die Lesbarkeit schon so extrem betont wird, ist logisch, dass es gar keine Kommentare geben sollte. Denn Kommentare dienen meist dazu, Quellcode verständlich zu machen. Oder sie kommentieren etwas aus. Und das wird dann allermeist vergessen. Und wozu eigentlich ewig auskommentieren, wenn man doch ein Quellcodeverwaltungssystem hat, wo jede Änderung zurück gespielt werden kann.
Natürlich führt Martin auch in die Praktik der testgetriebenen Entwicklung ein und man könnte meinen, dass er es damit nicht so eng sieht, wenn er dem Thema nur einige Seiten widmet.
Klassen sollten Gemäß Robert C. Martin – alias Uncle Bob – genauso klein sein wie Funktionen und genauso wie für Funktionen gilt das Prinzip, dass sie nur ein Thema behandeln sollten. Da eine Klasse eine Organisation von Funktionen ist, spricht man vom Single Responsibility Principle (SRP). Gemäß diesem Prinzip gibt es für eine Klasse nur einen Grund, geändert zu werden. D.h. die Klasse sollte so atomar sein, dass alle Änderungen den gleichen Grund haben. Ein Maßstab, wie kompakt eine Klasse ist, ist die Kohäsion. Maximale Kohäsion ist gegeben, wenn alle Methoden alle Klassenelemente benutzen. Eine hohe Kohäsion ist anzustreben, maximale Kohäsion meist nicht möglich. Folge des Strebens nach Kohäsion sind viele kleine Klassen.
Gleich zu Beginn wird der Leser auf eine Herausforderung eingeschworen. Und er bekommt versichert, dass es harte Arbeit wird, das Buch durchzuarbeiten. Ich übersetze das so, dass es harte Arbeit ist, Clean Code in der Realität mehr und mehr hervorzubringen. Die Motivation bzw. die Dringlichkeit, den Zustand der Sauberkeit nicht unerreichbar zu lassen, wird jedenfalls gegeben. Martin zeigt einen Grafen, auf dem die Produktivität mit der Zeit asymptotisch gegen 0 geht, wenn Code einfach nur gedankenlos entwickelt wird, um Feature für Feature zu produzieren. Eine Grafik, die auch einen Manager zum Nachdenken anregen sollte. Er sollte die Qualität seiner Entwickler und seiner Ressource Quellcode gut im Auge behalten. Schließlich ist auf langfristig schrumpfender Produktivität doch kein Geschäftsbiotop vorstellbar. Die Entwickler könnten durch ihren täglichen Krampf auch auf die Idee kommen, ein neues System zu entwickeln. Gerade heute habe ich in der iX wieder gelesen, dass 50% !!! aller hochqualifizierten Beschäftigten in der Informationsbranche über Zeitmangel klagen. Ich wette, sie klagen auch über ständig rauchende Köpfe. Nun wird also ein System von vorne begonnen, dass das alte ersetzen soll. Natürlich werden dafür nur die fähigsten, teuersten und schnellsten Entwickler gebraucht. 10 Jahre später ist es soweit. Das neue System steht. Aber wo sind die Entwickler? Sie sind schon wieder weggelaufen, weil der Programmcode in 10 Jahren schon wieder verrottet ist. Diese Geschichte zeigt, dass man nicht umhin kommt, den vorhandenen Code immer und immer wieder anzufassen, zu warten und zu refaktorisieren, bis er sauber ist.
Die Geschichte erinnert mich an eine sehr ähnliche Geschichte aus Michael Feathers Working Effectively with Legacy Code. Feathers erzählt sie Leuten, die unter den Altlasten stöhnen, die ihnen vorangegangene Programmierer hinterlassen haben. Also eigentlich erzählt er genau die gleiche Geschichte. Ist auch kein Wunder, denn Robert C. Martin ist der Chef von Michael Feathers. Natürlich machen ein neues System, eine neue Technologie oder eine neue Programmiersprache nichts besser, wenn die dieselben Programmierer mit den selben Methoden und nach denselben Mustern und Prinzipien arbeiten. Und in Wirklichkeit kann das alte Produkt keiner ersetzen. Denn das ist das Produktivsystem, mit dem das Geld verdient wird.