Sauberer Code im Vergleich zu Implementierungsmustern

Ich habe gerade Robert C. Martin's Clean Code und Kent Beck's Implementation Patterns hintereinander gelesen. Eigentlich habe ich Clean Code zuerst in die Hand genommen, weil meine Kollegen davon geschwärmt haben. Aber dann wird in Robert Martins Buch bereits auf der dritten Seite des ersten Kapitels aus Kent Becks Buch zitiert und dem Zitat widersprochen, also beschloss ich, dass es Spaß machen würde, auch Implementation Patterns zu lesen. :-)

Nun, es stellt sich heraus, dass die Bücher gar nicht so sehr voneinander abweichen. Der Unterschied besteht darin, dass Robert Martin sehr davon überzeugt ist, dass er einen guten Weg für uns alle beschreibt, während Kent Beck einen eher neutralen Ton anschlägt und bescheiden die Muster vorstellt, die ihn persönlich zu einem besseren Programmierer gemacht haben. Ich denke, das ist Geschmackssache, aber mir hat die Kühnheit von Clean Code besser gefallen. Ein weiterer großer Unterschied besteht darin, dass Clean Code viel mehr tatsächlichen Code enthält (um den es ja in beiden Büchern geht) als Implementation Patterns. Der Hinweis in der Einleitung von Clean Code, dass man die Fallstudien mit dem Code nicht auslassen sollte, damit das Buch nicht nur ein weiteres "Wohlfühlbuch" über Programmierung wird, ist sehr zutreffend. Ich bin mir nicht sicher, aber es kommt mir so vor, als ob diese Zeile an Kent Becks Bemühungen gerichtet war ;-)

Abgesehen von diesen Unterschieden ist das Schöne an beiden Büchern der erfrischende neue Fokus auf die kleinen Dinge, die uns zu besseren Programmierern machen. Nachdem wir alle GoF's Design Patterns gelesen hatten, wurde in vielen Büchern über Design Patterns und dann über Architektur Patterns gesprochen. Und danach verlagerte sich unsere Aufmerksamkeit auf die Prozesse (XP, Agile). Es ist gut, sich daran zu erinnern, dass die "alltägliche" Aufgabe des Codeschreibens etwas ist, das wir immer noch verbessern können und müssen.

Etwas anderes, was diese Bücher gemeinsam haben, ist ein sehr wichtiger Wert, den Sie beim Schreiben von Code im Auge behalten sollten. Und das ist Kommunikation (wie Kent Beck es in einem Wort zusammenfasst). Der Code, den Sie schreiben, wird öfter gelesen werden, als er geschrieben wurde, und zwar von mehr Leuten. Um also die Kosten für die Wartung zu minimieren, sollte Ihr Code für die Personen (oder Sie selbst), die ihn später lesen, verständlich sein. Er sollte schön zu lesen sein, sein Design klar vermitteln und nicht übermäßig komplex sein.

Dies zeigt sich in solchen Heuristiken (wie sie in Clean Code genannt werden) oder Mustern (wie sie in Implementation Patterns genannt werden) wie:

• Wählen Sie beschreibende Namen (CC) / Intention-Revealing Name (IP) - Denken Sie über die Namen nach, die Sie Ihren Klassen, Methoden usw. geben. Anstatt einfach mit get oder set zu beginnen und ein oder zwei Wörter hinzuzufügen, sollten Sie tatsächlich beschreiben, was vor sich geht. Wenn Sie das nicht kurz und bündig tun können, brauchen Sie vielleicht eine bessere Abstraktion.
• Funktionen sollten nur eine Abstraktionsebene herabsteigen (CC) / Zusammengesetzte Methode (IP) - Teilen Sie große Methoden so auf, dass sie nur eine Abstraktionsebene behandeln und die Arbeit an andere Methoden für die Arbeit auf einer niedrigeren Abstraktionsebene delegieren. Dadurch wird der Code nicht nur leichter zu verstehen, sondern Sie können auf diese Weise auch wiederverwendbare Teile des Codes entdecken. Mit der Unterstützung moderner IDEs für Refactoring-Operationen wie "Methode extrahieren" ist dies ein Kinderspiel.
• Verwenden Sie erklärende Variablen (CC) / Role-Suggesting Name (IP) - Teilen Sie komplexe Berechnungen auf, indem Sie lokale Variablen mit beschreibenden Namen verwenden. Wie das vorherige Muster hilft dies dem Leser Ihres Codes zu verstehen, was vor sich geht. Moderne IDEs verfügen über die Refactoring-Operation "Lokale Variable extrahieren", um dies zu erreichen.

Ein schöner Vorteil dieser Muster oder Heuristiken ist, dass Sie auf eine Menge Kommentare verzichten können. Kommentare, die manchmal redundant sind, die zwangsläufig veraltet sind und die den Leser sogar in die Irre führen können, wenn sie nicht richtig gepflegt werden. Da ich das Programmieren in den späten achtziger Jahren gelernt habe (als das Schreiben von Kommentaren das war, was ein guter Programmierer tun sollte), kam mir das zunächst etwas seltsam vor. Aber jetzt, wenn ich das Gefühl habe, dass ich einen Codeblock durch einen Kommentar erklären muss, weiß ich, dass ich diesen Block in eine separate Methode auslagern muss. :-)

Während mich beide Bücher sehr inspiriert haben, gab es ein paar Dinge, die mir nicht gefallen haben.

Um mit Clean Code zu beginnen: Robert Martins Prosa ist zwar sehr verlockend, aber die Kapitel, die von anderen Personen beigesteuert wurden, waren nicht auf demselben Niveau. Das Kapitel über Emergenz bietet keine neuen Erkenntnisse, und die Kapitel über Nebenläufigkeit wirken vereinfacht. Zumindest für jemanden, der das hervorragende Java Concurrency in Practice von Brian Goetz gelesen hat. Auch der Kodierungsstil, bei dem Felder gegenüber Methodenargumenten bevorzugt werden (wie das Beispiel Args in Kapitel 14 zeigt), scheint mir Probleme mit der Gleichzeitigkeit geradezu herauszufordern. Es sieht aus wie der Geruch von Hidden Temporal Couplings, der in demselben Buch erwähnt wird.

Was die Implementierungsmuster betrifft, so hätte ich mir, wie bereits erwähnt, gewünscht, dass das Buch mehr Code enthält. Außerdem sind einige der Muster nicht wirklich Muster, sondern eher Beschreibungen eines Programmierkonzepts ("Klasse", "Initialisierung", "Parameter", usw.). Während also auf der Rückseite des Buches 77 Muster versprochen werden, erhalten Sie in Wirklichkeit weniger ;-) Und es gibt ein Muster, das ich für sehr gefährlich halte. Ich habe so oft gesehen, wie Leute das Muster der eifrigen Initialisierung falsch interpretiert haben, dass ich gerne ein Muster gesehen hätte, das die Deklaration zur Initialisierung verschiebt, anstatt die Initialisierung zur Deklaration. Und schließlich werden im letzten Kapitel zwar einige nette Muster beschrieben, die man beim Schreiben eines Frameworks verwenden kann, aber diese Muster werden nicht auf das Timer-Framework in Anhang A angewandt, das unmittelbar folgt.

Eine Sache, die ich in beiden Büchern schmerzlich vermisse, ist der Umgang mit bestehenden Frameworks. Der meiste Code, den wir schreiben, existiert nicht in einem Vakuum, sondern verwendet eine Menge Frameworks wie EJB3, Spring, Wicket oder was auch immer. Obwohl moderne Frameworks im Vergleich zu älteren Frameworks wie EJB2 weniger invasiv sind, haben sie immer noch Auswirkungen auf Ihre Architektur, wie ich kürzlich beim Einsatz von JPA in einem neuen Projekt feststellen musste (aber dazu mehr in einem späteren Blog :-)).

Abschließend möchte ich sagen, dass diese Bücher eine wertvolle Lektüre für jeden sind, der ein besserer Programmierer werden möchte. Da sie leicht zu lesen sind (Implementation Patterns umfasst nur etwa 150 Seiten!), gibt es wirklich keine Entschuldigung mehr, schlechten Code zu schreiben!