Clean Code vs. Philosophie des Softwaredesigns

• Ein Gespräch über Softwaredesign zwischen Robert „Uncle Bob“ Martin und John Ousterhout, das von September 2024 bis Februar 2025 geführt wurde
• Beide haben Bücher über Softwaredesign geschrieben
• Bei drei Hauptthemen (Methodenlänge, Kommentare, Test-Driven Development) zeigten sich unterschiedliche Ansichten
• Im Kern ging es darum, wie sich die Komplexität von Code verringern, die Lesbarkeit erhöhen und Tests angemessen schreiben lassen

Methodenlänge

• Uncle Bob (im Folgenden UB) betont die Position: „Kurze Funktionen sind gut, und wenn möglich, sollten sie noch weiter aufgeteilt werden“
  • Eine Methode sollte nur eine einzige „Aufgabe (One Thing)“ erfüllen
  • Wird das jedoch zu extrem angewendet, kann es zu übermäßiger Zerlegung (over-decomposition) kommen
• John weist darauf hin, dass zu kleine Methoden es eher erschweren können, den Gesamtfluss zu verstehen
  • Wenn es viele „flache (shallow) Methoden“ gibt, entsteht das Problem, dass man alle zusammenhängenden Methoden ansehen muss, um eine Funktion zu verstehen
  • Die gegenseitige Abhängigkeit zwischen Methoden („entanglement“) steigt, wodurch das Lesen des Codes belastender wird
• Beispiel PrimeGenerator
  • UBs ursprünglicher Code war in etwa acht kleine Methoden aufgeteilt, die eng miteinander verflochten waren und deshalb schwer zu verstehen waren
  • Johns Version war so geschrieben, dass sich der Gesamtfluss durch eine einzelne Methode mit ausführlichen Kommentaren auf einen Blick erfassen ließ
  • Auch UB räumte bis zu einem gewissen Grad ein, dass es eine „übermäßige Zerlegung“ gegeben hatte
• Letztlich erkennen beide an, dass die Zerlegung von Code wichtig ist, aber der Schlüssel darin liegt, ein Gleichgewicht zwischen „zu klein aufteilen“ und „zu groß belassen“ zu finden

Kommentare

• UB betrachtet Kommentare als ein „notwendiges Übel (necessary evil)“
  • Kommentare werden seiner Ansicht nach oft nicht aktualisiert oder bergen das Risiko, falsche Informationen zu enthalten
  • Er bevorzugt es, die Absicht so weit wie möglich direkt im Code sichtbar zu machen und bei Bedarf sehr lange Namen zu verwenden
• John vertritt die Ansicht, dass Kommentare unbedingt notwendig sind
  • Wenn der Zweck einer Schnittstelle (Methode) oder die Implementierungsabsicht klar in Englisch festgehalten wird, spart das anderen Entwicklern Zeit, die sie sonst mit unnötigem Herumstöbern im Code verbringen würden
  • Seiner Ansicht nach ist „das Gefährlichste die Situation, in der es keine Kommentare gibt und man den Code direkt selbst interpretieren muss“
• Am Beispiel von PrimeGenerator weist John darauf hin, dass es ohne Kommentare, die erklären, „warum der Algorithmus so funktioniert“, sehr schwer zu verstehen ist
• UB meint, dass „Kommentare eher schaden, wenn sie nicht korrekt sind“, während John eher die Position vertritt, dass „fehlende Kommentare schädlicher sind als falsche Kommentare“
• Beide stimmen bis zu einem gewissen Grad darin überein, dass „je nach Team und Situation ein angemessenes Maß an Kommentaren“ nötig ist, insgesamt misst John dem Wert von Kommentaren jedoch deutlich mehr Bedeutung bei

Johns PrimeGenerator-Refactoring

• John strukturierte den ursprünglich in acht Methoden aufgeteilten Code zu einer einzelnen Methode oder zu 2–3 Methoden um
• An den nötigen Stellen fügte er ausführliche Kommentare ein, um zu erklären, „warum auf diese Weise implementiert wird“
• Mit Kommentaren beschrieb er sowohl die Absicht zentraler Variablen (multiples, primes) als auch die Funktionsweise des Algorithmus, um das Verständnis des Codes zu beschleunigen
• UB erklärte, dass auch dieser Code nicht vollständig intuitiv gewesen sei
  • Um einen komplexen Algorithmus zu erklären, brauche es weiterhin Zeit, und auch der Autor selbst habe im Überarbeitungsprozess Schwierigkeiten gespürt

Bobs PrimeGenerator2-Refactoring

• Eine Version, in der UB Johns Code leicht verändert hat
• Durch zusätzliche Aufspaltung einiger Methoden wurde ein „anschließendes Refactoring“ durchgeführt
  • Im Schleifenteil wurde die Lesbarkeit erhöht, allerdings trat vorübergehend ein Leistungsabfall auf
• John wies darauf hin, dass „zu stark in kleine Methoden aufgeteilter Code Leistungsprobleme verursachen kann“, woraufhin UB den Code erneut änderte und die Performance verbesserte
• Wegen UBs Vorliebe, „Kommentare zu minimieren“, bleibt John jedoch bei seiner Ansicht, dass „mehr Erklärungen das Verständnis erleichtern würden“

Test-Driven Development

• UB empfiehlt aktiv den TDD-Ansatz, bei dem in kurzen Zyklen zuerst Tests geschrieben und dann schrittweise gerade so viel Code ergänzt wird, dass die fehlschlagenden Tests bestehen
  • Er argumentiert, dass sich so die Testabdeckung jederzeit aufrechterhalten und aufwendiges Debugging vermeiden lässt
  • Seine Position ist, dass der Code durch häufiges Refactoring schrittweise sauberer wird
• John äußert die Sorge, dass TDD zu stark in eine „taktische Herangehensweise“ abgleitet
  • Seine Kritik lautet, dass „das Design zuerst kommen sollte, TDD aber dazu verleitet, zuerst Code zu schreiben (eine Minimalimplementierung für den Test)“
  • Er ist der Ansicht, dass gutes Design einen etwas breiteren Blick auf einmal erfordert und dass es besser ist, Tests gebündelt (bundling) für den betreffenden Code zu schreiben
• UB betont, dass es zwar Probleme geben könne, „wenn TDD falsch angewendet wird“, dass es bei korrekter Praxis aber sowohl der Testabdeckung als auch dem Redesign (Refactoring) helfe
• John äußert die Sorge, dass „TDD gerade für Anfänger eher das Risiko birgt, dass Code schnell chaotisch wird“
• Am Ende stimmen beide darin überein, dass „sowohl TDD als auch der Bundling-Ansatz großartigen Code hervorbringen können, wenn man sie richtig umsetzt“, unterscheiden sich aber darin, welcher Ansatz besser ist

Schlusswort

• John:
  • Er befürchtet, dass „Clean Code“ die Aufteilung in zu kleine Funktionen und die Unterdrückung von Kommentaren zu stark betont, wodurch Leser dem Ansatz in extremer Form folgen könnten
  • Ohne ausreichend Kommentare werde Code schwer verständlich, und Entwickler müssten am Ende mehr Zeit investieren
  • Er weist außerdem darauf hin, dass TDD das Design im großen Ganzen aus dem Blick verlieren kann
• UB:
  • Er erklärt, dass in der 2. Auflage von „Clean Code“ einiges ergänzt wurde und einige von Johns Ansichten eingeflossen sind
  • Bei allem Respekt für unterschiedliche Erfahrungen und Perspektiven betont er als gemeinsamen Nenner, dass letztlich alle sauberen und gut wartbaren Code anstreben sollten
• Zusammenfassend messen beide der Bedeutung von Softwaredesign und dem Ziel, „Code leicht lesbar zu machen“, höchste Priorität bei
• Unterschiede bestehen jedoch bei Kriterien für die Aufteilung von Methoden, beim Einsatz von Kommentaren und bei der Reihenfolge des Testschreibens
• Entscheidend ist letztlich, ein Gleichgewicht zu finden, das zur Teamumgebung und zur Codestruktur passt, und sich kontinuierlich um Verbesserungen am Design zu bemühen

[mhj5730]

Ich habe mehrere Bücher aus der Clean-Reihe, aber ich finde, sie eignen sich eher nur als Referenz auf einer metakognitiven Ebene. Wenn man sie wie Prinzipien oder Gesetze behandelt, wird es extrem anstrengend und ist auch nicht besonders praxisnah. Uncle Bob redet zwar ständig über die SOLID-Prinzipien, aber persönlich finde ich nicht, dass da besonders viel wirklich Praktisches dabei ist.

[ahwjdekf]

Ich denke, Code Complete und Clean Code teilen sich den 1. Platz im Ranking der am stärksten überschätzten Bücher.

[carnoxen]

Gibt es von The Philosophy of Software Design eine Übersetzung? Ich habe danach gesucht, aber nichts gefunden.

[mageia]

Paradoxerweise prägen sich eher ironische Bücher wie „Wie man so codet, dass es schwer zu warten ist“ ein als Bücher nach dem Muster „Das ist guter Code“.

[aer0700]

In letzter Zeit hatte ich wohl eher mehr Streit wegen Leuten, die Fans eines bestimmten Tech-Stacks oder einer Architektur sind und so reden, als würde etwas Schlimmes passieren, wenn man diesen Tech-Stack oder diese Architektur nicht einführt. Man sollte das je nach Situation anwenden; etwas, das ausnahmslos gut ist, scheint es nicht zu geben.

[yadameda]

Eine großartige Diskussion.

[spilist2]

Wenn ich so darüber nachdenke, habe ich Johns philosophy of sw design auch Juniors empfohlen, aber clean code nicht wirklich.

[bbulbum]

Ich denke, wichtig ist, nicht bloß blind irgendwelchen Schlagzeilen zu folgen, sondern den Kontext gut zu verstehen und entsprechend anzuwenden.

[savvykang]

Ich denke, Selbsthilfebücher zum Coden sind für Anfänger ohne eigene Vorstellungen von Technologie oder Implementierung durchaus in Ordnung, aber je mehr Erfahrung man sammelt, desto geringer wird ihr Nutzen. Es gibt weder eine absolute Wahrheit, die zu jedem Projekt und jeder Umgebung passt, noch lassen sich allgemeine Regeln auf jede Situation anwenden. Wie bei Ratgebern in anderen allgemeinen Bereichen scheint es besser zu sein, mit etwas Abstand an solche Empfehlungen heranzugehen, nur die zur jeweiligen Situation passenden Ratschläge anzuwenden und ihnen nicht blind zu folgen.

[nicewook]

Ich kann Johns Aussage etwas mehr nachvollziehen.
Im Kern geht es wohl darum, den Aussagen der beiden nicht dogmatisch und bedingungslos zu folgen, sondern zu verstehen, warum sie so argumentieren, und darauf aufbauend weiterzugehen.

[leojineoo]

Man darf nicht vergessen, dass Clean Code kein Ziel, sondern ein Mittel ist.

[ilikeall]

Letztlich kommt es darauf an, das richtige Maß zu finden.

[elddytbt]

Sehr nützlich 👍🏻

[GN⁺]

Hacker-News-Kommentare

• Manche Menschen können bei bestimmten Themen sehr dogmatisch sein. Ich kann nicht verstehen, warum man so etwas wie ein Evangelium übernimmt

  • Ich musste schon mit Leuten umgehen, die jedes Mal wütend wurden, wenn das 80-Zeichen-Limit pro Zeile überschritten wurde
  • Diese Tendenz ist nicht nur bei Programmierstilen, Mustern und Idiomen stark, sondern noch stärker bei Tech-Stacks und Lösungsarchitekturen
  • Gespräche mit Leuten, die einfach wortwörtlich zitieren, was sie in Büchern oder Blogs gelesen haben, sind äußerst frustrierend
  • Während des Hypes um NoSQL und Microservices war das besonders schlimm, und auch bei PaaS/SaaS und Containerisierung spürt man es weiterhin
  • Apps, Lambdas oder Transformationsaufgaben, die nur grundlegende Funktionen ausführen, erhöhen bloß den Wartungsaufwand und bringen keinen Wert
  • Der einzige Unterschied zwischen den Leuten, die Bücher oder Blogs geschrieben haben, und mir ist, dass sie etwas geschrieben haben. Man sollte immer im Kopf behalten, dass ihre Meinungen keine Fakten sind

• Wenn man einmal ein Projekt erlebt hat, das den Empfehlungen von Uncle Bob blind folgt, erkennt man, wie gering ihr Wert ist

  • Er hat zwar einige Texte produziert, um Software Engineering zu verbessern, aber sie sind voller schrecklicher Ratschläge
  • Sein Erfolg basiert auf dem endlosen Bedürfnis von Junior-Entwicklern nach Orientierung
  • Code mit viel Indirektion wird in einen Zustand gebracht, in dem er schwer zu bearbeiten ist

• Clean Code ist nur eines der Werkzeuge im Werkzeugkasten eines guten Software Engineers

• Manche Leute "refaktorieren", indem sie einfach nur benachbarte Zeilen gruppieren, statt Funktionen dann auszulagern, wenn sie wiederverwendet werden oder logisch Sinn ergeben

  • Als ich im Studium Clean Code gelesen habe, bekam ich den allgemeinen Vibe von Uncle Bob mit
  • Das scheint aus der Denkweise zu kommen, dass eine Funktion X Zeilen lang sein sollte
  • Ich bin dankbar für die Inline-Funktion moderner IDEs und strukturiere Code zum Verständnis entsprechend um

• Es gibt einen wichtigen Fall, der bei der Bedeutung von Kommentaren nicht erwähnt wurde

  • Beim Schreiben von USB-Gerätetreiber-Software kann man das Gerät leicht in einen falschen Zustand bringen
  • Jedes Mal, wenn ich einen Workaround implementiere, füge ich einen Kommentar zur Dokumentation hinzu
  • Ohne Kommentare ist es für andere schwer, die Absicht des Codes zu verstehen

• "A Philosophy of Software Design" ist sehr zu empfehlen

  • Entscheidend ist, die Qualität einer Abstraktion am Verhältnis zur Komplexität zu messen
  • Nachdem ich andere Bücher mit Programmier-Ratschlägen gelesen hatte, wurde mein Code nicht besser

• Vor der Clean-Code-Bewegung war das eine Reaktion auf reale Probleme der Softwareindustrie

  • Clean Code ging in eine bessere Richtung, wurde dann aber überkorrigiert
  • Ich weiß nicht, ob die Leute wieder zu riesigen Methoden und tief verschachtelten Bedingungen zurückkehren werden

• Bobs Meinung zu Kommentaren ist seltsam

  • Die Paranoia wegen falscher Kommentare ist absurd
  • Ich habe viel Zeit durch unklaren Code verschwendet
  • Statt seltsame Diagramme zu zeichnen, wäre es einfacher, den Algorithmus kurz zu erklären oder einen Link bereitzustellen

• Aus den Büchern von Uncle Bob wächst man mit der Zeit heraus

  • Wenn man den Richtlinien aus Clean Code folgt, lernt man etwas über "Überzerlegung"
  • Kleine Funktionen tun am Ende gar nichts mehr
  • Wenn man guten Code schreiben will, sollte man guten Code lesen und einen eigenen Geschmack entwickeln

• Es gibt Unmut über den Namen Clean Code

  • Die Sauberkeit von Code lässt sich nicht objektiv messen
  • Problematisch ist der unbewusste Anteil, dass das Schreiben von "sauberem Code" selbstverständlich gut sei
  • Die Grundlage von "Uncle Bob" war von Anfang an verdorben