Eine Ampel fuer die Codebasis

Jedes Team, das ueber eine Handvoll Beitragender hinauswaechst, kennt denselben langsamen Verfall. Eine Datei beendet die Anweisung mit Semikolon, die naechste nicht. Jemand laesst eine ungenutzte Variable stehen, ein anderer ueberschreibt einen Namen, der drei Ebenen hoeher schon vergeben war, und ein asynchroner Aufruf geht hinaus, ohne dass jemand seinen Fehlerfall abfaengt. Nichts davon bricht den Build heute. Alles davon kostet in einem halben Jahr jemanden einen Nachmittag. Die Durchsicht kann diese Klasse von Problem nicht fangen, weil sie in jedem einzelnen Commit auftaucht.

Das Werkzeug ist absichtlich unspektakulaer. Es liest die Quelldateien Anweisung fuer Anweisung und vergleicht sie mit einer Liste von Regeln. Jede Regel besitzt genau eine Form: eine ungenutzte Bindung, ein Promise ohne Empfaenger, ein Vergleich, der immer wahr ist, ein Zweig, der nie laeuft. Bei einem Treffer meldet es Stelle, Regelname und Stufe. Die Stufe ist die Spalte, die Teams unterschaetzen. Regeln sind nicht gleich schwer, und ein Bericht, in dem alles gleich laut ruft, ist so viel wert wie kein Bericht.

Regeln stehen in der Konfiguration, nicht im Geschmack

Der Unterschied zu den Pruefern davor: fast nichts ist fest verdrahtet. Jede Regel laesst sich abschalten, zur Warnung herabstufen oder zum Fehler hochstufen, und jede nimmt eigene Optionen. Ein Team, dem eine Schreibgewohnheit nicht gefaellt, schaltet sie ab und arbeitet weiter. Ein Team, das von einem bestimmten Fehlermuster getroffen wurde, stuft die passende Regel zum Fehler hoch und diskutiert nie wieder darueber.

Das Erweiterungsmodell folgt derselben Ueberlegung. Probleme, die zu einem Framework gehoeren, bleiben in eigenen Paketen, statt in den Kern geschoben zu werden: eine Sammlung fuer typabhaengige Pruefungen, eine fuer Komponenten, weitere pro Framework oder pro Testbibliothek. Ein Projekt installiert nur, was es braucht, und die Konfiguration bleibt kurz, weil jede Zeile darin eine Regel nennt, die tatsaechlich laeuft.

Zwei Oberflaechen nutzen dieselbe Regelmenge. Im Editor erscheinen Verstoesse waehrend des Tippens, unterstrichen und mit dem Regelnamen beim Ueberfahren, was die meisten Korrekturen von einem Review-Kommentar in ein paar Sekunden Arbeit verwandelt. In der Integrationsstrecke laeuft dieselbe Konfiguration ueber das ganze Depot und stoppt den Build, sobald ein Fehler auftaucht. Der Editor faengt den Fehler, solange der Zusammenhang im Kopf noch geladen ist. Die Strecke faengt, was einem mueden Menschen durchgegangen ist.

Was sich in dieser Generation geaendert hat

Das Format der Konfiguration wurde neu gebaut. Die alte Kaskade geerbter Dateien, mit ihren Erweiterungsketten und der Geltung, die sich aus dem Ordner ergab, ist ersetzt durch ein flaches Feld, in dem jeder Eintrag genau angibt, fuer welche Dateien er gilt. Das Ergebnis laesst sich leichter nachvollziehen, leichter debuggen und schneller laden, zum Preis einer einmaligen Umstellung, die die meisten Projekte schon hinter sich haben.

Die automatische Reparatur ist im selben Zug breiter geworden. Ein grosser Teil der Regeln kann den beanstandeten Code umschreiben, statt ihn nur zu beschreiben, und die Umschreibungen bleiben vorsichtig, damit ein Lauf das Verhalten nicht still veraendert. Formatierung, das unwichtigste Thema jeder Durchsicht, verschwindet weitgehend, sobald die Reparatur beim Speichern und noch einmal vor dem Commit laeuft.

Eine Regelmenge ist genau so viel wert wie die Vereinbarung dahinter. Das Werkzeug garantiert nur eines: eine getroffene Vereinbarung gilt weiter, nachdem alle, die sie ausgehandelt haben, laengst in einem anderen Projekt sitzen.

Verwaltung zaehlt bei so langweiliger Infrastruktur. Das Projekt haengt unter einer offenen Stiftung, veroeffentlicht in vorhersehbarem Takt und fuehrt eine veroeffentlichte Politik fuer brechende Aenderungen, weshalb ein grosses Depot eine Hauptversion annehmen kann, ohne die Featurearbeit fuer ein Quartal anzuhalten.

Wo es sich rechnet und wo nicht

Fuer eine einzelne Person entfernt eine gut gepflegte gemeinschaftliche Konfiguration eine ganze Klasse von Fehlern vor dem ersten Commit. Fuer ein Team ist der Wert von anderer Art. Ein Stilhandbuch im Wiki wird befolgt, solange nichts dringend ist. Dasselbe Handbuch als Regeln laeuft bei jedem Push, fuer jeden Beitragenden, auch fuer den, der letzte Woche dazukam.

Die Grenze verdient dieselbe Sorgfalt. Das Werkzeug vergleicht Formen in der Syntax, es ist kein Typpruefer und keine Testsuite. Es sagt nicht, dass eine Funktion zur Laufzeit die falsche Form liefert, und nicht, dass ein Feature kaputt ist. Es macht auch kein Design besser. Ein Depot mit dreihundert Regeln und ohne Tests bleibt ein Depot ohne Tests.

Eine bescheidene Reihenfolge schlaegt eine vollstaendige Liste. Mit der Konfiguration anfangen, die die Gemeinschaft schon pflegt, sie eine Woche nur berichten lassen und schauen, was tatsaechlich anschlaegt. Regeln hochstufen, die echte Probleme fingen; Regeln abschalten, die nur Laerm machten; den Rest in festem Abstand durchsehen. Eine Regel, die alle zu ignorieren gelernt haben, ist schlimmer als keine, weil sie das Team trainiert, den Bericht zu ignorieren.