Martin (arp242) hat kürzlich ein Legacy-Projekt übernommen. Das Erste, was er tat – bevor er sich den Code überhaupt ansah – war dieser Befehl:
git log --no-merges --format=format:'%b' | sed '/^$/d' | wc -lErgebnis: 295. In 13 Jahren brachte es dieses Projekt auf exakt 295 Zeilen Commit-Messages. Zieht man Dependabot-Commits, „revert commit” und „fix typo” ab, bleiben 167 Zeilen. Im Schnitt: eine Zeile pro Monat.
Keine Dokumentation. Fast keine Kommentare. Und die dreiwöchige Übergabe des Vorgängers war kommunikativ auf exakt demselben Niveau wie das Commit-Log. „Ich habe noch nie so sehr nachempfunden, warum Jack Bauer zu extremen Methoden der Informationsbeschaffung greift”, schrieb Martin. „Ich hätte es versuchen sollen.”
Die zwei Seiten des Zauns
Chestertons Zaun-Prinzip ist ein Klassiker der Softwareentwicklung: Du stolperst über ein seltsames Stück Code und willst es löschen – doch du solltest zuerst herausfinden, warum es überhaupt existiert. Es könnte eine Gefahr abwehren, die du nicht erkennst. Das ist die positive Seite. G.K. Chestertons Originalaussage: Ein Reformer muss, bevor er einen Zaun niederreißt, die Frage beantworten können, warum er dort errichtet wurde.
Martin zeigt die Kehrseite: Chestertons Mittelfinger.
„Ja, wir haben all diesen seltsamen Kram gebaut, aber wir haben nicht die Absicht, irgendjemandem zu sagen, warum. Fickt euch.”
Ein Zaun hat nur dann einen Sinn, wenn der Kontext bekannt ist. Wenn der Kontext mitsamt Commit-Messages, Kommentaren und Dokumentation verschwunden ist, wird der Zaun vom Schutz zum Fluch. Der nachfolgende Entwickler steht vor einer Ruine ohne Inschriften: ein Haufen unverständlicher Überbleibsel, die entweder monatelange Archäologie erfordern – oder den riskanten Abriss.
Drei toxische Commit-Muster
Martin hat keine systematische Taxonomie aufgestellt, aber seine Beschreibung zeichnet drei besonders zerstörerische Commit-Typen nach:
„fix page A” – die inhaltsleere Überschrift. Selbst bei umfangreichen Änderungen heißt der Commit-Titel nur „fix page A”. Die Überschrift transportiert null Information, der Body ist leer. Wer danach kommt, muss aus dem Diff Zeile für Zeile die ursprüngliche Absicht rekonstruieren – mit der Treffsicherheit einer Knochenorakel-Lesung.
WIP-Commits – gestrandete Halbfertigprodukte. Unvollendete Refactorings liegen verstreut im Code. Reste alter Funktionen wurden nie entfernt. Features, die hinzugefügt, aber nie verlinkt wurden und nie einen einzigen Nutzer hatten, schlummern tief in der Codebasis. Sie sind keine Bugs, aber schwieriger als Bugs. Bugs werden wenigstens gemeldet.
Der „Braucht-man-nicht”-Typ – Chestertons Lücke. Martin führt ein symmetrisches Konzept ein: Wenn Chestertons Zaun bedeutet „eine Mauer bauen, ohne zu sagen warum”, dann ist Chestertons Lücke das Gegenteil: „da, wo keine Mauer gebraucht wird, trotzdem eine hinstellen”. Abstraktionsschichten, die niemand verlangt hat. Overengineering. Vorab-Designs für ein Zukunftsszenario, das nie eintrat.
Zusammen ergeben diese drei Muster eine archäologische Katastrophe: Die Nachfolgenden müssen nicht nur verstehen, was der Code tut, sondern auch erschließen, warum die Vorgänger es so gemacht haben – und was sie sich damals eigentlich dabei gedacht haben.
Drei Fragen
Martin schlägt ein bodenständiges Framework für Commit-Messages vor – drei Fragen:
- Was hast du geändert?
- Warum hast du es geändert?
- Warum ist das eine gute Lösung?
„Implement new feature X” reicht manchmal, aber meistens gibt es immer etwas zu sagen – und sei es nur die Erklärung, warum ein bestimmter Parameter gewählt wurde, woher eine Annahme stammt oder welche Alternative verworfen wurde.
Es braucht kein elegantes Englisch. Kein philosophisches Essay. Dinge zu vergessen ist in Ordnung (aber aufschreiben ist besser). Die Untergrenze lautet: Es muss überhaupt etwas da sein. Jeder halbwegs ernsthafte Versuch ist unendlich viel besser als eine leere Zeile.
Martins Urteil ist unmissverständlich: „Commit-Messages schreiben ist keine optionale Zusatzaufgabe. Es gehört zur Arbeit. Wer keine schreibt, macht seinen Job nicht fertig.”
Lobsters-Konsens
Auf Lobsters bekam der Artikel 106 Punkte, und die Kommentare waren praktisch frei von Widerspruch. Ein Nutzer schrieb: „Ich habe fünf Jahre lang weltweit genau solche Codebasen saniert. Ich trage Working Effectively with Legacy Code mit mir herum wie eine Schmusedecke.”
Ein anderer Nutzer, david_chisnall, traf den Nagel auf den Kopf, was den Kernwert von Code Review ausmacht: „Der größte Vorteil von Code Review ist, dass er dich zwingt, jeden unausgesprochenen Kontext niederzuschreiben. Was du selbst nicht erklären kannst und was der Reviewer nicht versteht – genau das muss als Kommentar in den Code.”
Dazu ein immer wieder geschildertes Szenario: die Übernahme des Codes eines ausgeschiedenen Kollegen. Wenn du niemanden mehr fragen kannst, ist das Commit-Log die letzte Informationsquelle. Ist es leer, stehst du nicht vor Code – du stehst vor einer archäologischen Stätte, deren sämtliche Inschriften gezielt getilgt wurden.
Warum das heute besonders wichtig ist
KI-Coding-Tools – Codex, Claude Code, Copilot – katapultieren die Geschwindigkeit der Code-Produktion um Größenordnungen nach oben. Commit-Messages generieren sie dabei nicht automatisch. Schlimmer noch: Die automatisch erzeugten Nachrichten wie „Add files via upload” oder „Update code” sind gefährlicher als gar nichts, weil sie die Illusion von Dokumentation erzeugen.
Ein Projekt mit 295 Zeilen Commit-Messages in 13 Jahren wird im Zeitalter KI-gestützter Entwicklung nicht seltener – sondern häufiger. Denn Code produzieren ist schneller als kommentieren, und die KI kommt derzeit nicht von selbst auf die Idee: „Moment, hier sollte ich erklären, warum ich diese Datenstruktur gewählt habe und nicht jene.”
Martin schrieb zum Schluss: „Wer nichts schreibt, zeigt jedem, der danach kommt, den Mittelfinger.” Der Vergleich ist grob, aber er sitzt. Commit-Messages sind keine Notizen an dich selbst – sie sind eine Nachricht an dein zukünftiges Ich in drei Jahren, an die Kollegin, die deine Arbeit übernimmt, an die Person, die nachts aus der Rufbereitschaft gezogen wird, um eine Regression zu debuggen.
Das Material dieses Artikels stammt aus öffentlichen Informationen und Community-Diskussionen. Tiefere Praxiserfahrung zu diesem Thema? Hinweise auf Lücken sind willkommen.