Clean Code – Fazit

Erst zum Schluß, auf der allerletzten Seite gibt Robert C. Martin sich als testsüchtiger Programmierer zu erkennen. Martin ist bekennender Anhänger von Test Driven Development (TDD). Ich meine, er sollte von Anfang an darauf pochen, sich diese Praktik zu eigen zu machen. Ich habe selber erfahren, dass durch testgetriebene Entwicklung erst sauberer Code ermöglicht wird. Neulich hatte ich eine Anwendung, die ich nicht testgetrieben entwickelt hatte, nachträglich refaktorisiert, so dass ich sie testen konnte. Zuerst habe ich aus meinen zu testenden Klassen Funktionen extrahiert (indem ich die Signatur bewahrt habe – preserve Signature). Diese Funktionen malen in einer Zeichnung Pfeile und Markierungen und tun andere zeichnungsbezogene Dinge. Ich habe erkannt, dass sie in eine Klasse mit hoher Kohäsion zusammengehören. Danach habe ich das, was meine Anwendung eigentlich tut, hinter ein Interface verbannt. Ich bin einer der vielen Entwickler, die das Glück haben, mit einer Legacy Code-Basis zu arbeiten (Machen wir uns nichts vor: So geht es fast jedem Entwickler). Meine Anwendung kommuniziert jetzt mit dem System über die Implemtierung von diesem Interface. Für die Unit-Tests wird das Interface durch ein Fakeobjekt implementiert. Wieder entstand eine wunderbare Einheit. Durch dieses Refactoring erkannte ich auch, wie kompliziert ich entwickelt habe, da ich mich hauptsächlich mit dem “Wie” statt mit dem “Was” beschäftigt hatte. Das kann beim Test First Ansatz nicht passieren, da man ständig im Kopf hat, was man eigentlich machen will. Ich habe auch durch die nachträgliche Refaktorisierung und saubere Abkopplung meiner Anwendung erkannt, mit wie viel Aufwand ich tatsächlich das Legacy-System befriedigt habe und wie viel an unabhängiger Logik noch übrig blieb. Aber dadurch lasse ich mich nicht entmutigen. Ich habe so enorm viel dadurch gelernt und wie Feathers in Working Effectively with Legacy Code schreibt, entstehen zuerst Inseln, die getestet sind. Aus den Inseln wird Größeres, bis Kontinente daraus entstehen.

Ich bin sehr froh darüber, dass ich dieses Buch gelesen habe und es hat mir enorm viel gebracht. Ich habe das nötige Selbstvertrauen bekommen, selbst komplexeste Anwendungen stabil und zuverlässig entwickeln zu können. Komisch finde ich, dass es sehr viele Entwickler gibt, die sich um Codequalität nicht scheren. Hier wird meines Erachtens viel zu naiv daran gedacht, schnell ein Ergebnis zu fabrizieren. Ähnlich wie die chinesischen Spielzeugautos, die schön aussehen, aber auseinanderfallen, wenn ein Kind sie berührt. Dabei kann man gerade mit unsichtbarer Hintergrundarbeit mit wenig Aufwand sehr viel erreichen. Das schlagende Argument ist, dass ein Entwickler 9/10 des Tages nunmal nicht damit beschäftigt ist, ein neues Feature zu entwickeln, sondern seinen eigenen Quellcode zu lesen und zu warten. Es ist bekannt, dass in der Informationstechnik eine Technik die nächste jagt. Dass man da nicht überall dabei sein kann noch sollte, verstehe ich völlig. Aber die Maßstäbe, sauberen Code zu entwickeln sind schon viele Jahre alt. Hier geht es nämlich um Prinzipien, Muster und Praktiken, statt aus dem Boden schießende Technik. Ähnlich wie Design Patterns, die ihr 25. Jubiläum gefeiert haben und unabhängig von Computersprachen sind. Hier hat man eine ruhige tiefe Stelle im Meer weit unter der Oberfläche gefunden, eine Invariante in der Informationstechnik. Von hier aus hat man eine stabile Basis, sich vorwärts zu bewegen.

Clean Code – Teil II

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.

Clean Code – Teil I

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.

Clean Code – Motivation Produktivität

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.