Robert C. Martin: Clean Code

You are currently viewing Robert C. Martin: Clean Code

Robert C. Martin
Mit Beiträgen von: Michael C. Feathers, Timothy R. Ottinger, Jeffrey J. Langr, Brett L. Schuchert, James W. Grenning, Kevin Dean Wampler
Übersetzung: Reinhard Engel
Clean Code: Refactoring, Patterns, Testen und Techniken für sauberen Code

1. Auflage
2009, 475 Seiten, Broschur
mitp-Verlag
ISBN: 978-3-8266-5548-7

Informationen zum Buch im Katalog der Deutschen Nationalbibliothek.



Clean Code hat als Thema den, nun ja, „Clean Code“, den guten, sauberen Code. Das Buch enthält Regeln hierfür und sehr viele Beispiele anhand derer man erkennen kann, was die Autoren darunter verstehen. Clean Code ist ein sehr erfolgreiches Buch und das zu Recht.


Struktur

Clean Code, das erste von Robert C. Martins Büchern, dessen Titel mit dem Wort „Clean“ anfängt (Clean Agile ist das bisher vierte und letzte Buch mit dem „Clean“-Präfix), weist eine dreiteilige, etwas eigenwillige Strukturierung auf. Alternative (implizit vorhandene) Strukturierungen sind möglich und werden im Folgenden nach der Vorstellung der „offiziellen“ Struktur besprochen.

Die in der Einführung beschriebene Struktur sieht die Kapitel 1 bis 13 als ersten Teil an. Darin geht es um einfache Sachen, wie die Benamsung von Variablen oder die optimale Länge von Funktionen aber auch um komplexe Aspekte, wie emergentes Design oder Nebenläufigkeit. Teil zwei besteht aus den Kapiteln 14 bis 16, worin es um die Anwendung der im ersten Teil gelernten Prinzipien anhand von konkreten Codebeispielen geht. Kapitel 17, betitelt Smells und Heuristiken, ist der dritte Teil und stellt den „Lohn“ des geduldigen Lesers, der es so weit geschafft hat, dar, wie es Martin in der Einführung schreibt.

Während der zweite Teil klar umrissen ist (Anhang B gehört eigentlich ebenfalls dazu), stellt sich beim Thema Nebenläufigkeit, das in Kapitel 13 und in Anhang A behandelt wird, schon die Frage, ob es ganz dem ersten Teil zugerechnet werden kann, nur anteilig (Kapitel 13) oder vielleicht auch gar nicht. Ebenfalls gibt es eine gewisse Unschärfe, was den restlichen ersten Teil betrifft: dadurch, dass es einerseits um ganz Konkretes, Codenahes und andererseits um abstraktere Angelegenheiten, wie Schnittstellen oder Design, geht, wäre eine weitere Unterteilung möglich. Kapitel 17 ist eine Art Zusammenfassung in Listenform und kann somit als „Nachschlagewerk“ angesehen werden.

Die folgende Zusammenfassung geht davon aus, dass Anhang A ebenfalls zum ersten Teil gehört und Anhang B wird dem zweiten Teil zugerechnet.

Inhalt

Teil 1

Was ist sauberer Code? Um das zu erfahren befragt Martin, der auch als Uncle Bob bekannt ist, einige der Größen des Software Engineerings. Ward Cunningham, Ron Jeffries, Dave Thomas und einige andere kommen zu Wort im ersten Kapitel. Teilweise sind sich deren Antworten ähnlich, teilweise auch nicht. Clean Code ist Uncle Bobs und die seiner Mitautoren Antwort auf diese Frage.

Als Erstes ist es wichtig Variablen, Funktionen und Klassen aussagekräftig und selbstsprechend zu benamsen. Funktionen sollen klein sein und lediglich eine Aufgabe erfüllen. Kommentare, wenn unbedingt nötig, sollen aussagekräftig sein und kein „Geschwätz“ (S. 97f.) darstellen. Bevor man aber unverständlichen Code durch einen Kommentar verständlicher macht, solle man den Code umschreiben. Und Formatierungen sind wichtig, vor allem innerhalb eines Teams solle die Formatierung einheitlich sein. Das Law of Demeter ist wichtig und die Art, wie man Fehler behandelt ebenfalls. So soll man z.B. keine Fehlercodes zurückgeben, sondern Exceptions werfen.

Anfangend mit Kapitel 8 geht es um höhere Konzepte: Grenzen, also Schnittstellen, Unit-Tests, wo es selbstverständlich u.a. um TDD (Test-Driven Development) geht. Kapitel 10 behandelt Klassen. Für diese sind z.B. die Einhaltung des Single-Responsibility-Prinzips (SRP) und des Open-Closed-Prinzips (OCP) nebst einer hohen Kohäsion wichtig. Factories, Dependency Injection, Aspektorientierte Programmierung und diverse Patterns sind hilfreich beim Aufbau größerer Systeme. Eine Kurze Diskussion zu emergentem Design und eine etwas umfangreichere Behandlung des Themas Nebenläufigkeit runden den ersten Teil ab.

Teil 2

Teil zwei zeigt anhand dreier Beispiele – ein Parser für Befehlszeilenargumente, ein Auszug aus der JUnit-Bibliothek und der SerialDate-Klasse, die Teil der JCommon-Library ist – wie das im ersten Teil Gelernte angewendet werden kann. Anhang B enthält die gesamte SerialDate-Klasse plus weiteren Code aus dem org.jfree.date-Package der JCommon-Bibliothek (über 50 Seiten Code). Der Sinn hinter der Übung ist klar, aber die Übung selbst ist wenig sinnvoll, solche abgedruckten Unmengen an Code nachvollziehen zu wollen ist mühsam. Die Warnung der Autoren in der Einführung, dass für die Bearbeitung dieses Teils mehrere Tage notwendig seien (S. 22), ist realistisch, hilft aber auch nicht weiter.

Teil 3

Der dritte Teil, also das 17. Kapitel, das Smells und Heuristiken betitelt ist, ist eine Art Zusammenfassung des Buches. Viele, leicht nachschlagbare sogenannte Code Smells werden aufgelistet. Teilweise handelt es sich um Kent Becks und Martin Fowlers Smells aus Fowlers Buch Refactoring: Improving the Design of Existing Code, teilweise auch um andere.

Diskussion

Clean Code beginnt mit einem Plädoyer für guten Code. Martin entscheidet sich dabei einen Satz aus Kent Becks Buch Implementation Patterns zu zitieren, der die Wichtigkeit von gutem Code infrage stellt (erster Satz des folgenden Zitats), um dann dagegen zu argumentieren (vgl. S. 27). Der Abschnitt aus Implementation Patterns, der durch diesen Satz begonnen wird, enthält aber eine wichtige Wahrheit, die für jede Diskussion über guten Code wichtig ist. Kent Beck schreibt:

Actually this book is built on a rather fragile premise: that good code matters. I have seen too much ugly code make too much money to believe that quality of code is either necessary or sufficient for commercial success or widespread use. However, I still believe that quality of code matters even if it doesn’t provide control over the future.

Kent Beck. Implementation Patterns. Addison-Wesley. 2007. S. XVI

Das obige Zitat beschreibt ein interessantes Paradox: guter Code, wie auch immer man diesen definiert, ist gleichzeitig wichtig und unwichtig. Für den guten Programmierer werden Ästhetik, Wartbarkeit und „Güte“ des Codes tendenziell immer wichtig sein, für den Geschäftsmann ist der finanzielle Erfolg wichtig. Beck unterstreicht, dass zwischen den beiden Aspekten kein kausaler Zusammenhang besteht. (Sogar die Korrelation dürfte ziemlich schwach sein.) Für Uncle Bob, dem das Thema Professionalität so wichtig ist, ist guter Code selbstverständlich keine „fragile Prämisse“, sondern eine Notwendigkeit. Guter Code ist eines der Merkmale, die einen guten Programmierer überhaupt ausmachen. Er hat sicherlich Recht, Programmierer sollten aber auch Becks Worte nicht außer Acht lassen, das Hauptziel der Auftraggeber ist finanzieller Natur und die Güte des Codes hat oft nichts damit zu tun.

Martins Buch richtet sich jedoch nicht an Geschäftsleute, sondern an Programmierer, die besser werden wollen und das ist der Hintergrund, vor dem das Buch betrachtet werden muss. Man kann Clean Code vorwerfen, dass es ihm an Originalität mangelt, es stellt letztendlich eine Synthese anderer erfolgreicher Schriften dar. Unter diesen sind solche Klassiker wie Design Patterns: Elements of Reusable Object Oriented Software vom sogenannten Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides), Working Effectively with Legacy Code von Michael Feathers und Refactoring: Improving the Design of Existing Code von Martin Fowler (mit Beiträgen weiterer Autoren). Es handelt sich jedoch um eine sehr gute Synthese, die nicht von Ungefähr zum Verkaufsschlager aufgestiegen ist. Im Amazon Bestseller-Top in der Kategorie Bestseller in Softwareentwicklung befindet sich die englische Version des Buches auf Platz 1 (Abruf 26.01.2021).

Während gegen den ersten Teil wenig Negatives gesagt werden kann, ist der zweite Teil eine Zumutung für den interessierten Entwickler. Der Entwickler hat sich durch abgedruckte Unmengen von Code durchzuwühlen, um Martins Refactoring-Schritte nachvollziehen zu können. Der Nutzen längerer Code-Schnipsel sollte immer sorgfältig abgewogen werden, seitenweise Codeabschnitte sind aber immer eine schlechte Idee.

Die Trennung des Themas Nebenläufigkeit wirft die Frage nach dem Grund für diese Entscheidung auf. Schuchert schreibt, dass der zweite Teil, also der Anhang A, für Entwickler gedacht wäre, die mehr zum Thema Nebenläufigkeit wissen wollen (vgl. S. 218). Das ist eine kleine Inkonsequenz: für einen Profi sollte sich diese Frage gar nicht stellen, selbstverständlich muss der professionelle Programmierer alles zum Thema Nebenläufigkeit wissen.

Die englische Ausgabe von Clean Code ist 2008 erschienen (Copyright-Datum 2009). Es stellt sich die Frage, was davon 2021 noch gültig ist, und was vielleicht mittlerweile an Relevanz verloren hat. Die kurze Antwort ist: es ist alles noch (fast) genauso relevant, wie 2008 (den zweiten Teil ausgenommen). Eine neue Fassung würde sicherlich hie und da Anpassungen und Aktualisierungen beinhalten, aber im Großen und Ganzen dürfte das Buch auch als zweite Auflage ähnlich aussehen – was die objektorientierte Programmierung (OOP) anbelangt, hat sich ja auch nicht so Vieles geändert. Allerdings, ist OOP auch nicht mehr das, was es 2008 war, ich kann mir eine zweite Auflage nicht ohne ein längeres Kapitel zum Thema funktionale Programmierung vorstellen. Wahrscheinlich würde sich für eine zweite Auflage auch die Frage stellen, ob Java noch die Sprache ist. So hat Martin Fowler für die zweite Auflage von Refactoring: Wie Sie das Design bestehender Software verbessern auch JavaScript für die Code-Beispiele verwendet (in der ersten Auflage war es selbstverständlich noch Java).

Ein sehr erfahrener und guter Programmierer wird heute wahrscheinlich Clean Code nicht mehr viel abgewinnen können, für alle anderen dürfte sich die Lektüre von Uncle Bobs Bestseller jedoch lohnen.


Zu den Autoren

Robert C. Martin

Informationen über Robert C. Martin finden Sie auf der separaten Buchautorenseite.

Weitere Beitragende

Im Folgenden aufgelistet in der im Buch angegeben Reihenfolge mit jeweiligem Beitrag:

  • Michael C. Feathers: Autor des siebten Kapitels betitelt Fehler-Handling
  • Timothy R. Ottinger: Autor des Kapitels 2 mit dem Titel Aussagekräftige Namen
  • Jeffrey J. Langr: Autor der Kapitel 10 und 12 betitelt jeweils Klassen und Emergenz
  • Brett L. Schuchert: Autor der Inhalte zum Thema Nebenläufigkeit (Kapitel 13 und Anhang A)
  • James W. Grenning: Autor des achten Kapitels mit dem Titel Grenzen (d.h. Schnittstellen)
  • Kevin Dean Wampler: Autor des Kapitels 11 benannt Systeme

Folgende Rezensionen könnten Sie ebenfalls interessieren:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Nachdem er sein Bachelorstudium im Fach Psychologie abschloss, orientierte er sich neu und studierte Software Engineering an der Hochschule Heilbronn, ebenfalls mit einem Bachelor abgeschlossen. Anschließend war er knappe sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Aktuell ist er mit dem Masterstudium der Praktischen Informatik und der Rezensionsplattform für IT-Fachbücher nososo.de beschäftigt.

Schreibe einen Kommentar