Allgemeine Informationen
Das Buch wurde vom Programmier-Popularisierer und erfahrenen Entwickler Robert Martin geschrieben. Es geht darum, wie man besseren und saubereren Code schreibt. Lassen Sie uns das Buch kurz durchgehen.
Kurze Übersicht der Kapitel
Das erste Kapitel ist rein theoretisch und etwas trocken. Es erklärt die Bedeutung, guten Code zu schreiben und dass es mit jedem Monat teurer wird, schlechten Code zu warten – sowohl in Bezug auf Geld als auch Zeit.
Es folgt eine Erklärung, wie man Variablen am besten benennt: Sie sollten die Absichten des Programmierers widerspiegeln, und beim Lesen der Variablen sollte sofort klar sein, welche Daten sie enthält und welchen Typ sie hat. Es wird empfohlen, abstrakte Namen wie List, Data usw. zu vermeiden. Außerdem wird kurz die Benennung von Methoden und Klassen behandelt – dies ist jedoch mehr ein Thema für andere Abschnitte, die der Autor später detaillierter behandelt. Es gibt viele Ratschläge, und die meisten davon sind ziemlich logisch und vernünftig. Einerseits ist es ein banales und offensichtliches Kapitel, andererseits könnte es für Anfänger sehr nützlich sein.
Es folgt das Thema Funktionen. Hier beginnen die kontroversesten Themen – wie viele Zeilen eine Funktion haben sollte und wie viele Parameter sie haben darf. Natürlich ist die Antwort offensichtlich: Je kleiner und einfacher die Funktion, desto besser. In der Praxis ist das jedoch oft nicht der Fall. Es wird auch die logische und vernünftige Idee erwähnt, dass eine Funktion nur eine bestimmte Aufgabe erledigen sollte. Das bedeutet zum Beispiel, dass eine Funktion nicht gleichzeitig den Durchschnitt berechnen und das Ergebnis auf dem Bildschirm ausgeben sollte – wie bei den SOLID-Prinzipien. Darüber hinaus gibt der Autor in diesem Kapitel auch Ratschläge zum Umgang mit Bedingungen (if, else, switch), Schleifen und der try/catch-Struktur. Natürlich wird auch das Thema Funktionsbenennung und das DRY-Prinzip (Code nicht wiederholen) behandelt.
Nach den Funktionen folgt ein weiteres kontroverses Thema – Kommentare: Wie und wo man sie setzen sollte und wo sie überflüssig sind. Juristische, zeitschriftenmäßige und einige andere Arten von Kommentaren werden vom Autor behandelt, wobei gezeigt wird, wann sie wirklich angebracht sind.
Wenn Sie denken, dass das Thema Kommentare umstritten ist, was sagen Sie dann über die Formatierung? Dieses kleine Kapitel folgt nach den Kommentaren. Und wenn man denkt, es geht nur um Tabs und Leerzeichen – dann ist das nicht der Fall. Das Kapitel ist viel informativer. Der Autor fügt sogar verschiedene Diagramme bei.
"Arbeiten mit Objekten und Datenstrukturen" – so heißt das nächste Kapitel. Abstraktion, Asymmetrie der Daten, das Demeter-Gesetz, DTO, Active Record und einige andere Themen werden in diesem kurzen Kapitel behandelt. Es wird eher oberflächlich behandelt, und der Schwerpunkt liegt darauf, dass der Programmierer bereits mit diesen Konzepten vertraut ist.
Es folgt das Kapitel über Fehlerbehandlung. Viele Beispiele im Buch sind in Java, sodass Sie keine Fehlerbehandlung im Golang-Stil (über if) finden werden. Der Schwerpunkt liegt auf try/catch. Wenn vor ein paar Kapiteln noch die Rede von Formatierung war, geht es jetzt darum, wann, wo und wie man Ausnahmen behandelt.
Das nächste Kapitel, "Grenzen", bezieht sich nicht auf den Code im Allgemeinen, sondern mehr auf die Architektur, genauer gesagt auf das Zusammenstellen und die Verwendung von Modulen. Der Abschnitt ist klein, sodass sich diejenigen, die Robert Martins Ansichten zur sauberen Architektur interessieren, seine separate Ausgabe zu diesem Thema ansehen sollten.
Weiter geht es mit "Tests". Ein paar Worte zu TDD, dann direkt darüber, wie ein Test aussehen sollte. Das Kapitel ist klein und nicht besonders informativ. Wenn jemand sich für das Thema Testen interessiert, kann ich ein großartiges Buch empfehlen, und wahrscheinlich werde ich es bald durchgehen.
Danach folgt das Kapitel "Klassen". Wenn man Klassen als Teil der Codeverbesserung betrachtet (und genau das tut Onkel Bob), dann ist das Material dieses Abschnitts durchaus ausreichend. Aber nur, wenn die Entwickler bereits mit OOP vertraut sind. Andernfalls, wenn man objektorientierte Programmierung tiefer lernen möchte, wird dieser Abschnitt wenig informativ oder sogar schwierig sein.
Die nächsten Kapitel widmen sich wieder der Architektur. Nein, es geht nicht um die geschichtete Architektur im üblichen Sinne, die Martin in einem anderen Buch empfiehlt. Hier geht es mehr um grundlegende Dinge. Das erste Kapitel behandelt eher verschiedene Blockdiagramme als Code. Einige Muster – wie abstrakte Fabriken, Dependency Injection und Proxy – werden kurz erwähnt. Insgesamt sind die Kapitel gut und informativ.
Es folgt das Kapitel zur Multithreading-Theorie. Mehr Theorie als Praxis: Es gibt nicht so viel Code, vorwiegend theoretisches Material, und auch das nur oberflächlich.
Die nächsten Kapitel behandeln Refactoring von Code anhand von Beispielen von Robert Martin. Und hier gibt es, im Gegensatz zu einigen vorherigen Kapiteln, viel Code. Zunächst behandelt der Autor das Refactoring eines Kommandozeilen-Tools, dann geht es weiter mit einigen Java-Bibliotheken / -Klassen erfahrener und bekannter Entwickler. Selbst bei diesen Spezialisten findet Martin noch Punkte, die er kritisiert – und aus meiner Sicht sind das eher Kleinigkeiten als echtes Refactoring. Denn der Code funktionierte auch, und die Testabdeckung war hoch. Die Hauptbotschaft dieses Kapitels lautet: Es reicht nicht aus, einfach funktionalen Code zu schreiben – er muss auch leicht wartbar sein, sonst wird es irgendwann sehr schwierig.
Das letzte Kapitel ist eine Art Zusammenfassung, bestehend aus Ratschlägen, die alles umfassen, was bereits behandelt wurde: von Anmerkungen in Kommentaren bis hin zu Funktionen und Tests.
Fazit
Vorteile des Buches
- Die Struktur des Buches ist gut durchdacht. Es besteht aus 17 Kapiteln, wobei jedes Kapitel eine kleine Steigerung im Vergleich zum vorherigen darstellt. Mit anderen Worten, beim Erlernen einer Programmiersprache beginnt man mit den Grundlagen (Variablen, Kommentare), und im Laufe der Komplexität geht es zu Funktionen, Klassen, Asynchronität usw. Etwa dieses Prinzip wird auch im Buch beibehalten, was bequem und vertraut ist.
- Die meisten Ratschläge sind wirklich nützlich und logisch. Einige werden viel Neues entdecken, andere fast nichts. Es hängt alles von der individuellen Erfahrung ab.
- Im Buch gibt es Illustrationen. Es sind nicht viele, aber die wenigen, die vorhanden sind, folgen einem einheitlichen Stil, was schon angenehm ist.
Minuspunkte des Buches
- Man sollte nicht alle Ratschläge fanatisch befolgen. Es gab mindestens einige, wenn nicht sogar viele „Ratschläge“, mit denen ich nicht ganz einverstanden bin oder die ich überhaupt nicht teile.
- Das Buch ist ziemlich dick – etwas mehr als 450 Seiten. Und große Bücher sind für viele nicht leicht zu lesen.
- Die Refactoring-Beispiele (Löschen und Hinzufügen von Zeilen) könnten besser dargestellt werden. Derzeit werden Änderungen nur durch Fett (hinzugefügt) und Durchgestrichen (entfernt) angezeigt. Eine Darstellung im Stil von Git-Clients wäre vielleicht für viele vertrauter.
- Als Beispiele wird Java verwendet. Ich habe nichts dagegen und hatte keine Schwierigkeiten beim Verständnis, aber für diejenigen, die mit der Sprache nicht vertraut sind, könnte das ein Nachteil sein.
- Ich habe eine Ausgabe von 2010 erwischt. Möglicherweise gibt es neuere Auflagen. Das Buch, das ich gelesen habe, ist etwas veraltet. Es sollte nicht nur aktualisiert, sondern auch erweitert werden.
Gesamtfazit
Dieses Buch wird nicht umsonst als Bestseller im Bereich der Codeentwicklung angesehen. Es ist zumindest wert, schnell durchgeblättert zu werden, oder besser noch – gründlich studiert zu werden. Wenn keine Zeit oder Lust ist, das ganze Buch zu lesen, empfehle ich, sich die kurzen Schlussfolgerungen am Ende jedes Kapitels und das abschließende Kapitel mit allgemeinen Empfehlungen anzusehen. Nach dem Lesen wird es nützlich sein, die Ansätze und Ratschläge mit Kollegen zu diskutieren – denn blindes Befolgen der Empfehlungen von Robert Martin könnte nicht nur unangebracht, sondern auch fehlerhaft sein.
