Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.
Hauptgedanke
Code zu mergen, den niemand im Team erklären könnte, ist keine Nachlässigkeit beim Review: Es ist ein Kredit. Das Team bekommt das Feature sofort und verpflichtet sich, später mit der Unfähigkeit zur Diagnose zu bezahlen — dann, wenn dieser Code geändert, abgesichert oder übernommen werden muss, ohne dass man weiß, warum er so geschrieben ist.
Die Schuld bleibt unsichtbar, solange nichts bricht: Die Anwendung läuft, die Bildschirme antworten, die Tests laufen durch. Dutzende Pull Requests, die ein Assistent über Nacht eröffnet hat und die integriert werden, ohne dass jemand die Auswirkungen geprüft hat, sehen aus wie ein Vorsprung; in Wahrheit laufen Zinsen auf.
Daraus folgt eine einfache, fast brutale Merge-Regel: keinen Code integrieren, den niemand erklären kann. Sie verlangt keine endlose Dokumentation — ein kleines Verständnisbudget pro Feature genügt: der Vertrag, die Tests, die Architekturentscheidung, die bekannten Grenzen. Gerade genug, damit die Überlegung von Mensch zu Mensch weitergegeben werden kann.
Warum das wichtig ist
Das gibt dem Nichtverstehen wieder einen sofortigen Preis, und zwar an der Stelle und in dem Moment, an dem die Entscheidung fällt. Solange die Kosten aufgeschoben sind, wirkt jede einzelne Integration vernünftig, und die Schuld wächst, ohne dass eine Abwägung sie je in Kauf genommen hätte.
Es liefert auch ein Review-Kriterium, das nicht vom technischen Niveau des Prüfenden abhängt: Die Frage lautet nicht „Ist dieser Code gut?“, sondern „Kann hier jemand sagen, warum er so ist?“.
Nuancen und Grenzen
Die Regel stößt auf eine Grauzone: Erklären auf welcher Ebene? Niemand erklärt den Code einer Fremdbibliothek Zeile für Zeile, und ein Team, das diesen Grad überall verlangte, würde nichts mehr integrieren. Gegenstand der Erklärung sind die Absicht und die Grenzen, nicht jede einzelne Anweisung.
Und sie greift nur, wenn jemand befugt ist, eine Integration zu blockieren. In einem Team, in dem der Termin Vorrang hat, wird sie zur bloßen Absichtserklärung, und die Erklärung schrumpft zum abgehakten Kästchen.
Offene Fragen
- Worauf muss sich die Erklärung beziehen — das Feature, das Modul, die Zeile —, damit die Regel anwendbar bleibt, ohne zum Ritual zu werden?