Har bygget en kontrolmotor med 268 tjek

Situation. Standarder, der er skrevet ned i en contributing‑guide, er forslag. Alle er enige i dem, og så er det fredag, ændringen er lille, og guiden taber. Kravet om nul advarsler kunne kun holde, hvis noget andet end god vilje holdt det oppe — og de lintere, der følger med hvert sprog, når langtfra frem til de projektspecifikke regler, der faktisk betyder noget, dem, der handler om, hvordan netop denne kodebase er tænkt til at fungere.

Opgave. De regler, projektet gik op i, skulle kunne eksekveres, så et brud på én af dem fik committen til at fejle i stedet for at vente på en reviewer med tid og hukommelse nok til at opdage det.

Handling. Ud af det voksede en kontrolmotor. Der er 274 check‑scripts, hvoraf 268 er registreret i commit‑hooks, foruden 277 JavaScript‑lintere og 96 shell- og 17 Python‑validatorer, der dækker de ting, som standardværktøjer ikke har nogen holdning til — at en migration kan rulles tilbage, at en oversættelsesnøgle findes i begge locales, at en registreret rute optræder i OpenAPI‑beskrivelsen, at ingen i det stille har slået en regel fra direkte i koden. Femten egne ESLint‑regler håndhæver husets mønstre i TypeScript. Én regel er værd at nævne for sig: enhver commit med præfikset fix: skal have en test med, der fejler uden den, så en fejl, der er rettet, forbliver rettet. Og fordi en ødelagt kontrol er værre end slet ingen kontrol — den lader alt passere, og ingen opdager det — har kontrollerne selv 146 test.

Resultat. Review‑tiden flyttede fra mekanik til design, fordi de mekaniske indvendinger allerede var fremsat af en maskine, før branchen blev pushet. Bagsiden er reel og værd at sige højt: det er langsomt at committe, og en dårligt skrevet kontrol er virkelig frustrerende at arbejde uden om. De 146 test findes, fordi netop det skete.