Clean Code: A Handbook of Agile Software Craftsmanship [Kindle Edition]

Ich habe einige Kapitel gelesen und will mir noch kein abschliessendes Bild machen. Das was die anderen Rezensenten sagen, stimmt schon. Es ist wirklich ein gutes Buch über gepflegten Code. Nur an ein paar Stellen wird mir der Autor zu dogmatisch, deswegen sollte man nicht alles blind übernehmen. Am deutlichsten wurde mir das im Kapitel 3 über Funktionen.

Dort beschreibt er anhand einer unaufgeräumten Funktion wie er sie schrittweise verbessert, und gibt dabei den ersten Zwischenschritt und das finale Ergebnis preis. Dabei erstellt er im Zwischenschritt eine absolut verständliche, klare Funktion mit 11 Codezeilen und beschreibenden Funktionsaufrufen. Damit ist der Autor aber nicht zufrieden, bezeichnet die Funktion absurderweise als immer noch "too long" und legt nochmal Hand an, indem er fast jede Zeile in eine eigene Funktion packt. Der daraus resultierende Code hat fast doppelt soviele Zeilen wie der ursprüngliche Code den es zu verbessern galt! Der Autor wünscht sich, das sich der Code wie eine Geschichte lesen soll, zerstückelt ihn dabei aber derart das man meint man würde nun ein Buch lesen in dem auf jeder Seite nur ein Satz mit maximal 10 Worten steht. Ich kann seine Begeisterung für derart zerstückelten Code absolut nicht nachvollziehen, zumal die Bezeichnung der Funktionen immer abstruser wird, da nun nicht mehr nur 5-10 Funktionen sondern eher 25 nach einer sinnvollen Beschreibung verlangen. Ganz zu schweigen davon das man vom Einstiegspunkt aus nun jeden Funktionsübergang mitlesen muss, indem man die aufgerufene Funktion sucht, dort den nächsten Funktionsaufruf vorfindet, um sehr schnell nicht mehr zu wissen auf welchem "level" des callstacks man sich nun befindet. Im Kopf ist sowas nur noch schwer zu durchschauen, und Debugger-freundlich ist das auch nicht mehr.

Ergo: mir hat der Zwischenschritt mit 11 Zeilen wesentlich besser gefallen, er war auf jeden Fall auf einen Blick verständlich und nachvollziehbar. Darauf wollte ich hingewiesen haben, denn hier wird der Autor dogmatisch und schießt sich selbst ins Knie, in dem er seine Argumentationen ad absurdum führt und dennoch sehr deutlich darauf beharrt was für wunderschönen Code er daraus gezaubert hat. Dieser Dogmatismus ist es auf den ich hinweisen wollte, und wegen dem ich auch einen Stern abziehe.

Von den begeisterten Rezensionen hier geleitet habe ich mir das Buch zugelegt und direkt gelesen. Vorneweg, der Schreibstil ist sehr angenehm, es liest sich hervorragend.

Die Punkte, die im Buch abgearbeitet werden um aufzuzeigen, was guter Code ist und ihn von schlechtem Code trennt decken sich mit meinen Erfahrungen, die Argumentationen, warum etwas schlecht ist und besser anders gemacht wird, nachvollziehbar. Bei den meisten Punkten stimme ich überein, doch was mir ziemlich sauer aufgestoßen ist:

* (Zu) Java-zentriert. Das ist an sich ja nicht so schlimm, würde man nicht bei den Argumentationen das ein oder andere mal - jedenfalls aber zu oft während des Buchs - denken, dass das Argument nur in Java Gültigkeit besitzt.
* Martin vergleicht ziemlich am Anfang des Buches die Aufbröselung langer Methoden mit der Normalisierung von Datenbanken. Offenbar hat er aber vergessen, dass sehr oft aber auch wieder Denormalisiert wird, da die weitere Auftrennung den Kontext auseinander reisst. Er hat zwar recht, dass man nach Möglichkeit alles auseinanderbricht, aber er verliert kein Wort darüber, dass man damit oft auch zu viel des Guten erreicht.
* Eine wichtige Grundregel meiner Erfahrung: Algorithmen _nicht_ auseinanderbrechen. Das schreckliche Gegenbeispiel kommt auf Seite 145, in dem Martin Knuths Primzahlencode aus Literate Programming nimmt, nach Java portiert und anschließend nach seinen Methoden refactort. Das Ergebnis ist eine reine Zumutung für das Auge und hat mit Clean Code nichts mehr zu tun. Positiv zu erwähnen ist, dass er die Ausgabe und die Erzeugung getrennt hat. Die Ausgaberoutinen sind sauber und so nachzuvollziehen, wie er es gern hat: Wie ein Stück Prosatext. Aber der Algorithmus als solcher ist nicht mehr zu erkennen. Nicht alles sollte als Prosatext beschrieben werden!
* Leider noch mal der Java Einfluss, aber wer von präzisem, klarem Code spricht, sollte keine Methodennamen verwenden, die länger als 20 Zeichen sind. Das Primzahlbeispiel macht das klar. Eine Methode mit Namen isLeastRelevantMultipleOfNextLargerPrimeFactor sollte nicht von jemandem geschrieben werden der von sich behauptet, sauberen Code zu schreiben... Code-Normalisierung ja, aber bitte nur soweit man keine Algorithmen, die irgendwo anders mathematisch beschrieben und geprüft sind, mit lächerlich anmutenden Funktionsnamen zerstört. Martins Code hat meistens eine gewisse Eleganz, aber die Eleganz in einem wohlgeformten Algorithmus scheint er nicht zu kennen, im Gegenteil, er reisst sie auseinander.
* Leider wird an keiner Stelle im Buch erwähnt, welchen Einfluss die Veränderung des Quellcodes auf die Performance der Software hat. Dass er es mit der Performance in seinem Code nicht all zu ernst nimmt zeigt ein Beispiel, bei dem er einen String zurück gibt, in dem ein Großbuchstabe einen Schalter der auf an steht anzeigt, und einen Kleinbuchstaben, wenn der Schalter aus ist. Normal würde man das über ein Bitfeld machen, und nicht wie er vorschlägt besser mit StringBuffer. Leider lässt der Java Einfluss wieder grüßen.

Ich bin etwas enttäuscht von dem Buch. Bei vielen Stellen im Buch hab ich den Kopf geschüttelt und mir die Frage gestellt, was für ein Schmarrn das ist, was er da macht, da das so einfach nicht in allen Bereichen applikabel ist. Wer viel in Java programmiert wird seine Freude an dem Buch haben und sicher oft mit dem Kopf nicken. Wer unter Clean Code nicht (nur) maximal-aufgebrochene Funktionen mit elendig langen Funktionsnamen versteht wird mit dem Buch nicht glücklich und lediglich seine Vorurteile über Javaprogrammierer bestätigt finden. So jemand schaut sich besser nach anderen Büchern um und reicht das Buch an den fanatischen Javajünger in seinem Freundeskreis weiter ;)

Da mich das Thema sehr interessiert, habe ich mir dieses Buch aufgrund der Bewertungen vor zwei Wochen gekauft. Das Buch beginnt sehr gut mit einigen lesenswerten Zitaten zu dem Thema im ersten Kapitel. Auch das Regelwerk im letzten Kapitel finde ich weitgehend gelungen. Und würde sich das Buch nur auf diese knapp 50 Seiten beschränken, dann könnte ich mir bei einem dem Umfang angemessenen Preis eine Bewertung mit vier oder fünf Sternen durchaus vorstellen.

Die restlichen Kapitel sowie der Anhang sind langatmig, plagen durch Wiederholungen und strapazieren mit seitenweise Quellcode. Sie enthalten viele kontroverse und teils fragwürdige Aussagen - und aus meiner Sicht leider auch viele, die einfach nur falsch sind. Wirklich erschreckend finde ich aber die Beispiele für sauberen Code, die alle bei mir das zwingende Bedürfnis auslösen, sie stark umzuschreiben.

Viele Rezessionen bemängeln konkrete Punkte, und ich könnte selbst eine ganze Liste aufstellen. Doch eine solche Aufstellung würde meinem Entsetzen nicht gerecht werden.

Ich empfehle dieses Buch niemandem - außer er interessiert sich für schlechten Code. Und ich bitte die Leser, die sich nicht überzeugen und beschützen lassen wollen, zumindest die Kapitel 2 bis 16 zu überspringen.