Buchempfehlung und -Rezension: Clean Code von Robert C. Martin

Michael HönnigMichael Hönnig
Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code von Martin, Robert C. Martin ist ein Programmierlehrbuch der anderen Art, denn es lehrt seinen Programmcode sauber schreiben, so dass er leicht testbar, leicht lesbar und leicht änderbar ist. Endlich einmal setzt ein Buch den Fokus auf das, was jede Software im Endeffekt ausmacht: den Programmcode – und warum dieser sauber sein muss und wie man dieses erreichen kann. Meiner Meinung nach sollte das Buch Pflichtlektüre eines jeden Programmierers sein, gleich nachdem man Programmieren an sich gelernt hat! Aber auch für erfahrene Programmierer bietet das Buch eine gute Zusammenfassung vieler Prinzipien und Praktiken, teils als Erinnerung, teils als neue Einsichten. Sicherlich ist es nicht nur produktiver, sonst macht auch viel mehr Spaß, mit Kollegen zusammen zu arbeiten, die dieses Buch gelesen haben. Die Beispiele, in Java codiert, zeigen für fast alle Codierungs-Prinzipien ein „suboptimales“ Beispiel, dass dann bezüglich des jeweils erklärten Prinzips bezüglich Testbarkeit, Lesbarkeit und Änderbarkeit optimiert wird. Dass die Beispiele zumeist real existierender OpenSource-Software entnommen wurden, verdeutlicht den Praxisbezug. Die deutsche Übersetzung ist weitestgehend sehr gut lesbar, eigentlich fand ich nur die ersten Seiten etwas arg holprig, was aber auch am Original liegen könnte - oder ich habe mich an den Stil gewöhnt. Einige Kapitel sind von Fremdautoren, diese weichen auch teilweise in der Qualität etwas ab. Inhaltlich geht es nach einer allgemeinen Abhandlung über „sauberen Code“ u.a. um:
  • Namensgebung (zweckbeschreibend, eindeutig, aussprechbar, suchbar, typflexibel, der Problem- bzw. Lösungsdomäne entsprechend, kontextfrei),
  • dem Aufbau von und Verteilung auf Funktionen (Top-Down-Lesbarkeit, das Eine-Aufgabe-Prinzip, Funktionsargumente, Vermeidung von Nebeneffekten, Wiederholungen und Output-Parametern, der Verwendung von Exceptions etc.),
  • Kommentare (oft Hinweis auf Verbesserungspotentiale, gute + schlechte Kommentare, Schnittstellendokumentation wie z.B. JavaDoc, Vermeidung von auskommentiertem Code etc.), Formatierung (vertikale und horizontale Anordnung und Dichte, Zeitungs-Metapher, Einrückung, Team-Regeln),
  • Objekte- und Datenstrukturen (Datentransfer-Objekte, echte Objekte, Law-of-Demeter etc.),
  • Fehler-Behandlung (besser Exceptions als Rückgabe-Codes, Try-Catch-Blöcke, Unchecked Exceptions, Anforderungen des Aufrufers beachten, Null-Werte etc.),
  • Schnittstellen – er nennt es „Grenzen“ (Umgang mit Drittanbieter-Code, nicht existierendem Code),
  • Unit-Tests (Test-Driven-Development, saubere Tests, domänenspezifische Testsprache, ein Konzept pro Test, das F.I.R.S.T.-Prinzip: Fast, Independent, Repeatable, Self-Validating, Timely),
  • Klassen (Aufteilung auf Klassen, Skalierbarkeit, Factories und Dependency-Injection, Cross-Cutting-Concerns, Proxies AOP, Verwendung Standards),
  • Nebenläufigkeit (falsche Vorstellungen, Herausforderungen, Testbarkeit, Single-Responsibility-Prinzip, Umgang mit Daten und Datenaustausch, Thread-Sicherheit, Deadlocks, Synchronisation, Testbarkeit etc.),
  • Code-Smells und Heuristiken (hier folgt ein Regelwerk, angelehnt an das Buch Refactoring von Martin Fowler, das mich auch stark an die Checklisten der Evo-Methode von Tom und Kai Gilb erinnert),

Erfreulich undogmatisch auch, dass der Autor nicht der Meinung ist, man müsse mit allen seinen Prinzipien einverstanden sein. Bei mir waren es allerdings wenige, doch sollte sich da jeder seine eigene Meinung bilden ohne das Ziel aus den Augen zu verlieren: Testbaren, lesbaren und änderbaren Programmcode. Nicht nur die nachfolgenden Kollegen werden es danken, auch sehr bald die Kunden und das Controlling. ISBN 9783826655487 (deutsche Ausgabe), ISBM 9780132350884 (englische Originalausgabe)