Clean Code als Qualitätsmodell

Clean Code als Qualitätsmodell

0:00 Im zweiten Modul geht es um Clean Code — und ich muss gleich zu Beginn eine Erwartung dämpfen. Sie bekommen hier keine Regelliste. Regellisten gibt es reichlich, und sie richten mehr Schaden an, als man denkt, weil sie überall gleich angewendet werden. Stattdessen sehen wir uns die Ziele an, denen diese Regeln dienen. Wer die Ziele kennt, kann in einer konkreten Lage begründen, warum eine Regel hier hilft und dort schadet.

0:24 Das ist der Unterschied zwischen Handwerk und Ritual. Und wir werden zwei der meistzitierten Prinzipien überhaupt geradeziehen.

Clean Code als Qualitätsmodell

0:32 Wir bleiben am ersten Tag bei den Grundlagen. Nachdem das erste Modul die Werkzeuge sortiert hat, kommt jetzt der Qualitätsbegriff dahinter. Das ist keine Pflichtübung vor dem eigentlichen Thema — es ist die Voraussetzung dafür, ein Ergebnis überhaupt beurteilen zu können. Wer nicht sagen kann, was gut heißt, kann auch nicht sagen, ob ein generierter Vorschlag gut ist.

0:54 Und Sie werden merken: Zwei der bekanntesten Prinzipien werden fast überall falsch wiedergegeben.

Äußere und innere Softwarequalität

1:00 Fangen wir mit einer Unterscheidung an, die alt ist und deren wirtschaftliche Seite trotzdem regelmäßig bestritten wird. Software wird an zwei Fronten beurteilt, und nur eine davon sieht der Kunde. Das klingt zunächst nach einer akademischen Trennung. Tatsächlich entscheidet sie darüber, ob ein System in zwei Jahren noch wirtschaftlich änderbar ist — und darüber lässt sich, anders als viele glauben, durchaus mit Zahlen reden.

1:24 Denken Sie an ein Haus. Der Käufer sieht die Fassade, die Räume, die Heizung, die funktioniert. Was er nicht sieht, ist die Verkabelung hinter dem Putz — ob sie ordentlich verlegt ist oder ob jemand irgendwann eine Leitung quer durchs Haus gezogen hat. Genau so ist es bei Software. Die äußere Qualität ist das, was das System für seine Nutzer leistet: Es rechnet richtig, ist schnell genug, fällt nicht aus.

1:48 Die innere Qualität ist die Verfassung des Codes — wie lange jemand braucht, ihn zu verstehen, und wie riskant eine Änderung ist. Der Kunde bezahlt die äußere und bekommt die innere gratis mitgeliefert. Oder eben nicht. Hier wird es interessant, und zwar in beide Richtungen. Martin Fowler stellt fest, dass schlechter Code Entwickler bereits innerhalb weniger Wochen spürbar bremst — nicht erst nach Jahren.

2:11 Das ist die entscheidende Aussage, denn sie macht aus einer moralischen Frage eine ökonomische. Und er ist ehrlich genug dazuzusagen, dass diese Einschätzung auf der Befragung erfahrener Entwickler beruht und nicht auf einer Messung. Die zweite Zeile liefert Zahlen: fünfzehnmal mehr Defekte, hundertvierundzwanzig Prozent längere Fehlerbehebung.

2:30 Auch hier die Einschränkung mitlesen — die Autoren messen mit dem eigenen Werkzeug, und die Kausalrichtung ist offen. Schwieriger Code könnte auch schwierige Fachlichkeit spiegeln. Der Satz, um den es geht, lautet: Innere Qualität ist der Preis der zukünftigen äußeren Qualität. Ein System kann heute tadellos liefern und in zwei Jahren unbezahlbar sein.

2:52 Und die Kurven kreuzen sich früh — es gibt kaum eine Strecke, auf der Schludern sich tatsächlich auszahlt. Eine Ausnahme gehört ehrlich dazu: Wer wirklich nur Wochen Lebensdauer plant, darf sparen. Nur kommt dieser Fall fast nie vor, und fast jeder, der ihn für sich reklamiert, irrt sich. Der Prototyp, der nur kurz leben sollte, läuft erfahrungsgemäß fünf Jahre.

Vier Qualitätsziele statt einer Regelliste

3:15 Kommen wir zu dem Modell, das dieses Seminar verwendet. Statt Regeln zu sammeln, führen wir Clean Code auf wenige Ziele zurück. Vier Stück, nicht mehr. Der Vorteil liegt weniger in der Vollständigkeit als in der Anwendbarkeit — vier Ziele bleiben im Kopf, und man kann sie in einer Diskussion tatsächlich abrufen. Neun genormte Merkmale kann das niemand.

3:36 Jede Clean-Code-Regel, die Sie kennen, dient einem oder mehreren dieser vier Ziele. Das ist der entscheidende Unterschied zwischen Handwerk und Ritual. Wer die Ziele kennt, kann in einer konkreten Lage begründen, warum eine Regel hier hilft und dort schadet — und kann sie auch begründet brechen. Wer nur die Regeln kennt, wendet sie überall gleich an und wundert sich über das Ergebnis.

3:58 Sie kennen das aus Reviews, in denen ein Verstoß gemeldet wird, ohne dass jemand sagen kann, welchen Schaden er eigentlich anrichtet. Achten Sie auf die Formulierungen in der rechten Spalte, denn sie sind bewusst überprüfbar gehalten. Korrektheit heißt nachweisbar, nicht dem Vernehmen nach. Verständlichkeit misst sich an jemandem, der den Code nicht geschrieben hat.

4:20 Wandelbarkeit ist der schönste Satz von den vieren: Eine fachlich kleine Änderung soll auch technisch eine kleine Änderung sein. Wenn das nicht mehr gilt, wissen Sie, dass etwas schiefläuft — unabhängig davon, wie sauber der Code aussieht. Und Produktionseffizienz wird gern vergessen, weil sie erst im Betrieb weh tut. Diese Einteilung ist übrigens unsere, keine Norm; die genormte Referenz wäre ISO 25010, seit 2023 mit neun Merkmalen.

4:47 Zwei Hinweise dazu. Erstens: Halten Sie diese vier Ziele nicht für eine Norm. Sie sind bewusst gröber. Zweitens, und das ist ein netter Prüfstein für die eigene Aktualität: Wer ISO 25010 mit acht Merkmalen zitiert, ist auf dem Stand von 2011. Die Revision von 2023 hat neun, Usability heißt jetzt Interaction Capability, und Safety ist dazugekommen.

5:10 Wenn also jemand im Raum die Norm ins Feld führt, ist das kein Widerspruch, sondern ein guter Anlass, die Fassungen zu vergleichen. Der dritte Punkt ist der eigentlich schädliche: Regeln durchsetzen, ohne das Ziel dahinter zu benennen.

Lesbarkeit für Menschen, Navigierbarkeit für Agenten

5:26 Jetzt kommt der Aspekt, der wirklich neu ist. Code wird nicht mehr nur von Menschen gelesen. Das klingt nach einer Kleinigkeit, verschiebt aber die Gewichtung zwischen den bekannten Qualitätsmerkmalen — manche werden wertvoller, andere weniger wichtig. Sehen wir uns an, welche das sind, denn daraus folgen praktische Konsequenzen für die tägliche Arbeit.

5:46 Die gute Nachricht zuerst: Ein Coding-Agent findet sich in einer Codebasis über dieselben Signale zurecht wie ein neuer Kollege. Sprechende Namen, erwartbare Ablageorte, konsistente Muster, eine Struktur, die die Fachlichkeit widerspiegelt. Was Menschen das Lesen erleichtert, erleichtert dem Agenten das Finden. Sie müssen also nicht umlernen und auch nichts maschinengerecht verbiegen.

6:09 Die Investition in Lesbarkeit zahlt jetzt doppelt. Interessant wird es dort, wo die Gewichtung auseinandergeht — und das ist an drei Stellen der Fall. Die erste Zeile ist die praktisch wichtigste. Ein Mensch verzeiht eine inkonsistente Benennung, wenn er den Kontext kennt — er weiß eben, dass diese eine Klasse historisch anders heißt.

6:29 Ein Agent, der über Suche arbeitet, findet die abweichend benannte Stelle womöglich nicht und baut daneben eine zweite Lösung. Die zweite Zeile geht in die andere Richtung: Weit auseinanderliegende Dateien liest ein Agent mühelos zusammen, wo ein Mensch längst den Faden verloren hätte. Und die dritte ist die unangenehmste — implizites Wissen im Kopf. Der Agent kann nicht fragen.

6:51 Praktisch heißt das: Konsistenz wird wertvoller, und ungeschriebenes Wissen wird teurer. Der erste Punkt trifft fast jedes gewachsene Projekt: Man duldet eine Ausnahme von der Namenskonvention, weil ohnehin alle sie kennen. Das stimmte, solange nur Menschen suchten. Der zweite und dritte hängen zusammen — man erwartet, dass die besonders benannte Stelle schon gefunden wird, und bekommt stattdessen eine zweite Implementierung daneben.

7:17 Damit ist aus einer harmlosen Inkonsistenz eine echte Wissensduplikation geworden, und die kostet ab jetzt bei jeder Änderung. Der vierte Punkt ist die Wurzel: Konventionen pflegen, aber nirgends aufschreiben.

KISS und YAGNI gegen spekulative Komplexität

7:29 Jetzt zu zwei Ratschlägen, die zu den ältesten der Zunft gehören und die durch generative KI erheblich an Bedeutung gewonnen haben. Beide zielen auf denselben Gegner: Komplexität, die niemand angefordert hat. Und diese Sorte Komplexität entsteht heute leichter als je zuvor, weil sie nichts mehr kostet — jedenfalls nicht beim Erzeugen.

7:50 KISS verlangt die einfachste Lösung, die das Problem tatsächlich löst. YAGNI verlangt, nur zu bauen, was jetzt gebraucht wird. Beides klingt banal, und beides wird täglich verletzt. In der Praxis sieht das so aus: Sie bitten um eine Preisberechnung und bekommen eine Strategie-Hierarchie mit Registry und Konfiguration, wo drei Zeilen gereicht hätten.

8:10 Das Ergebnis ist nicht falsch — es funktioniert. Es kostet nur jeden künftigen Leser eine zusätzliche Ebene, die er durchschreiten muss, ohne dass jemals ein zweiter Fall auftaucht, der sie rechtfertigen würde. Der Umgang damit ist erfreulich mechanisch, und genau deshalb funktioniert er. Benennen Sie jeden Erweiterungspunkt im Vorschlag einzeln — allein das macht schon sichtbar, wie viele es sind.

8:34 Fragen Sie dann bei jedem: Welcher konkrete, heute bekannte Fall erzwingt ihn? Gibt es keinen, wird er gestrichen, und zwar ohne Diskussion über die Zukunft. Diese Diskussion führt nämlich nirgendwohin, weil beide Seiten recht haben können. Lesen Sie zum Schluss die gestrichene Variante und prüfen Sie, ob die Fachlichkeit jetzt besser sichtbar ist. Meistens ist sie das.

8:57 Der erste Punkt ist die häufigste Fehlanwendung überhaupt: YAGNI als Ausrede für fehlende Tests oder schlampigen Aufbau. Das ist nicht gemeint. YAGNI gilt für spekulative Funktionalität, ausdrücklich nicht gegen sauberen Aufbau. Der zweite Punkt ist der leiseste: Man behält den Erweiterungspunkt, weil er ja nicht weh tut.

9:17 Er tut aber weh — er kostet jeden Leser Aufmerksamkeit, dauerhaft. Und der letzte ist ein verbreitetes Missverständnis: Einfachheit ist nicht dasselbe wie Kürze. Kurz und undurchschaubar ist das Gegenteil von KISS.

DRY: Wissensduplikation statt ähnlicher Syntax

9:31 Jetzt kommen wir zu dem Prinzip, das von allen am häufigsten falsch verstanden wird. Und das Schöne daran ist: Wir müssen darüber nicht streiten. Die Autoren selbst haben die verbreitete Lesart ausdrücklich als Irrtum bezeichnet, und zwar in derselben Publikation, in der sie das Prinzip formuliert haben. Das macht diesen Punkt zum belastbarsten des ganzen Moduls.

9:52 DRY verlangt nicht, dass kein Codeabschnitt einem anderen ähneln darf. Es verlangt, dass ein Stück Wissen genau eine maßgebliche Stelle im System hat — eine fachliche Regel, eine Rechenvorschrift, ein Format. Hunt und Thomas haben das 1999 so formuliert und in der Jubiläumsausgabe zwanzig Jahre später richtiggestellt: Viele hätten es auf Code bezogen und gedacht, DRY heiße, nicht zu kopieren.

10:16 Es gehe aber um Duplikation von Wissen, von Absicht. Und Wissen ist mehr als Code — auch Datenbankschemata, Testpläne, das Buildsystem gehören dazu. Der Unterschied entscheidet über die Qualität jeder Zusammenfassung, und dieses Beispiel macht ihn greifbar. Oben: An zwei Stellen wird geprüft, ob sich Zeiträume überschneiden.

10:36 Das ist dieselbe Regel. Ändert sich die Definition von Überschneidung, muss sie sich an einer Stelle ändern — also zusammenführen. Unten: Die Validierung einer Buchung und die einer Kostenstelle sehen zufällig gleich aus, weil beide drei Felder auf Nichtleere prüfen. Das sind zwei unabhängige Regeln mit derselben aktuellen Ausprägung. Führt man sie zusammen, koppelt man zwei Dinge, die sich unabhängig entwickeln werden.

11:01 Die nächste Änderung wird dann teurer, nicht billiger. Fassen wir zusammen, warum das mehr ist als eine Begriffsklärung. Zufällig gleiche Regeln entwickeln sich auseinander — das ist keine Vermutung, das ist der Normalfall. Wer sie vorher zusammengeführt hat, muss dann eine Abstraktion aufbrechen, an die sich inzwischen Aufrufer gewöhnt haben.

11:22 Sandi Metz hat dafür den Satz geprägt, den Sie sich merken sollten: Duplikation ist weit billiger als die falsche Abstraktion. Wichtig ist das Adjektiv. Die richtige Abstraktion bleibt besser als beides — der Satz ist keine Erlaubnis zum Kopieren.

Single Responsibility und Änderungsgründe

11:38 Und damit zum zweiten großen Missverständnis. Auch hier hilft uns der Urheber: Robert Martin hat seine ursprüngliche Formulierung selbst als missverständlich erkannt und sie deshalb geändert. Wer die alte Fassung zitiert, zitiert eine, die der Autor inzwischen präzisiert hat. Sehen wir uns an, was tatsächlich gemeint ist — und warum die verbreitete Lesart so viel Schaden anrichtet.

12:01 Die Verantwortung eines Bausteins lässt sich schlecht an seiner Größe ablesen und gut an der Frage, wer seine Änderung veranlasst. Ein Modul hat eine Verantwortung, wenn alle Gründe, es zu ändern, aus derselben Ecke kommen. Martin hat das ursprünglich als ein Grund zur Änderung formuliert, wegen der Mehrdeutigkeit des Wortes Grund aber später umgestellt: verantwortlich gegenüber genau einem Akteur.

12:23 Seine eigene Kurzfassung lautet: Führe zusammen, was sich aus denselben Gründen ändert, und trenne, was sich aus verschiedenen ändert. Hier sehen Sie, warum das kein ästhetisches Anliegen ist. Die Abrechnungsklasse des Fahrtenbuchs wird von drei völlig verschiedenen Seiten angefasst. Vom Gesetzgeber, wenn sich das Steuerrecht ändert. Von der Verwaltung, wenn ein anderes Exportformat gebraucht wird. Und vom Betrieb, wenn der Mailversand umgestellt wird.

12:49 Drei Auslöser, drei Interessengruppen, ein einziger Codeblock. Die Folge steht in der rechten Spalte: Bei jeder dieser Änderungen besteht das Risiko, die anderen beiden zu beschädigen — von Leuten, die von den anderen beiden gar nichts wissen. Genau darum geht es beim Prinzip: unabhängige Änderungsanlässe zu entkoppeln. Der erste Punkt ist die Lesart, die Martin selbst als Missverständnis benannt hat: eine Klasse, eine Aufgabe.

13:15 Sie führt zu Klassen mit je einer Methode und ist der häufigste Grund, warum SRP als schädlich erlebt wird. Der zweite ist verwandt — nach Zeilenzahl schneiden statt nach Änderungsanlass. Der dritte ist der praktische: Die Akteure lassen sich nicht erraten, man muss in der Organisation nachsehen. Und daraus folgt der vierte, der viele überrascht: Derselbe Schnitt ist nicht in jeder Firma richtig.

Übung: Menschlicher und KI-gestützter Review im Vergleich

13:39 Zum Abschluss des Moduls eine Übung, die das Gelernte auf die Probe stellt — und zwar an einem Ausschnitt des Fahrtenbuchs. Es geht nicht darum, möglichst viele Fehler zu finden. Es geht darum, die gefundenen Befunde begründet zu ordnen, und zwar mit den vier Qualitätszielen als Maßstab statt mit Regelverstößen. Der Aufbau ist einfach und der Reiz liegt im Vergleich. Sie prüfen einen Ausschnitt zuerst ohne Werkzeug und notieren Ihre Befunde mit einer eigenen Einschätzung der Schwere.

14:07 Danach lassen Sie denselben Ausschnitt von einem Assistenten begutachten. Wichtig ist die Reihenfolge — wer zuerst die KI-Liste liest, bekommt sie nicht mehr aus dem Kopf. Ergiebiger als die Fundlisten selbst ist übrigens der Vergleich der Schwere-Einschätzungen. Dort widersprechen sich Mensch und Maschine am häufigsten, und dort lernt man am meisten über die eigenen Maßstäbe.

14:28 Fünf Schritte, eine Stunde. Erst allein prüfen, dann den Assistenten, dann beide Listen nebeneinanderlegen und die Schnittmenge markieren. Danach die drei Fragen: Was hat nur der Mensch gefunden, was nur die KI, und wo widersprechen sich die Einschätzungen zur Schwere? Der letzte Schritt ist der eigentliche Prüfstein. Wählen Sie drei Befunde zur Behebung aus und begründen Sie die Reihenfolge mit den vier Qualitätszielen — nicht mit Regelverstößen.

14:54 Wenn Ihnen dabei kein Ziel einfällt, war der Befund vielleicht keiner.