Un feu de signalisation pour le code

Des que le groupe depasse une dizaine de personnes, le meme relachement commence. Un fichier termine la ligne par un point virgule, le voisin ne le fait pas. Quelqu un laisse une variable inutilisee, un autre redeclare un nom deja pris trois niveaux plus haut, et un appel asynchrone part sans que personne ne recoive son echec. Rien de tout cela ne casse la construction aujourd hui. Tout cela coutera un apres midi a quelqu un dans six mois. La relecture ne peut pas attraper cette classe de probleme, car il apparait a chaque envoi.

La methode est volontairement sans eclat. Le programme lit les fichiers source une instruction a la fois et les compare a une liste de regles. Chaque regle possede une seule forme: une liaison inutilisee, une promesse sans destinataire, une comparaison toujours vraie, une branche qui ne passe jamais. En cas de correspondance, il signale la position, le nom de la regle et un niveau. Le niveau est la colonne que les equipes sous estiment. Les regles ne pesent pas le meme poids, et un rapport dans lequel tout crie aussi fort ne vaut rien.

Des regles dans la configuration, pas dans le gout

La difference avec les verificateurs precedents tient a un point: presque rien ne se trouve code en dur. Chaque regle peut etre coupee, abaissee en avertissement ou elevee en erreur, et chacune accepte ses propres options. Une equipe qui deteste une habitude de ecriture la coupe et repart au travail. Une equipe qui a souffert sur un type de defaut eleve la regle correspondante en erreur et ne revient jamais sur le sujet.

Le modele des extensions suit la meme logique. Les problemes propres a un cadre restent dans des paquets separes plutot que de etre pousses dans le noyau: un ensemble pour les verifications liees aux types, un pour les composants, d autres par cadre ou par bibliotheque de test. Un projet installe seulement ce dont il a besoin, et la configuration reste courte, car elle ne cite que des regles qui tournent vraiment.

Deux endroits consomment le meme jeu de regles. Pendant la frappe, les manquements apparaissent soulignes, avec le nom de la regle au survol, ce qui transforme la plupart des corrections en quelques secondes au lieu de produire un commentaire de relecture. Dans la chaine continue, la meme configuration parcourt tout le depot et arrete la construction quand une erreur apparait. Le premier attrape les erreurs tant que le contexte est encore present chez celui qui ecrit. Le second attrape tout ce qui a echappe a un humain fatigue.

Ce qui a change dans cette generation

Le format de configuration a ete reconstruit sur de nouvelles bases. L ancienne cascade de fichiers herites, avec ses chaines heritees et sa portee deduite du dossier, a laisse la place a un tableau plat ou chaque entree declare exactement a quels fichiers elle sapplique. Le resultat se lit mieux, se debugge plus vite et se charge plus rapidement, contre une migration unique que la plupart des projets ont deja faite.

La reparation automatique a gagne en portee au meme moment. Une large part des regles peut reecrire le code en cause au lieu de le decrire, et les reecritures restent prudentes: un passage ne modifie pas le comportement en silence. La mise en forme, sujet le moins interessant de toute relecture, disparait largement des que la reparation tourne a la sauvegarde puis une seconde fois juste avant le depot.

Un jeu de regles vaut exactement ce que vaut la convention qui le porte. Le programme garantit une seule chose: une fois la convention conclue, elle tient encore apres le depart de tous ceux qui ont negocie.

La gouvernance compte pour une infrastructure aussi ennuyeuse. Le projet siege sous une fondation ouverte, publie selon un rythme previsible et tient une politique ecrite pour les changements cassants, ce qui permet aux grands depots de prendre une version majeure sans geler le travail de fonctionnalite pendant un trimestre.

Ou cela rapporte, et ou cela ne rapporte pas

Pour une personne seule, une configuration communautaire bien tenue retire une classe entiere de defauts avant le premier envoi. Pour une equipe, la valeur change de nature. Un guide de style ecrit dans un wiki reste respecte tant que rien ne presse. Le meme guide exprime en regles tourne a chaque envoi, pour chaque personne, y compris celle qui est arrivee la semaine derniere.

La frontiere merite le meme soin. Cet outil compare des formes de syntaxe. Ce ne sera jamais un verificateur de types, et jamais une suite de tests. Il ne dira pas si une fonction renvoie une forme fausse a execution, ni si une fonctionnalite est cassee. Il ne rend pas une conception meilleure non plus. Un depot avec trois cents regles et sans test reste un depot sans test.

Un rythme modeste bat une liste complete. Commencer par la configuration que la communaute tient deja, la laisser seulement rapporter pendant une semaine et regarder ce qui se declenche vraiment. Elever les regles qui ont attrape de vrais problemes, couper celles qui ne produisaient que du bruit, et revoir le reste a intervalle regulier. Une regle que tout le monde a appris a ignorer est pire que pas de regle du tout: elle habitue le groupe a ignorer le rapport.