MENLO PARK (Californie) — Les assistants de programmation sont devenus doués pour produire du code qui a l’air juste. La question plus délicate, pour le développeur qui doit le fusionner, est de savoir si quelqu’un l’a vérifié. Remy, l’agent de programmation de Corepass, y répond par ce qui s’apparente à une traçabilité des preuves : un relevé des vérifications qu’il a lancées, de ce qu’il a modifié quand l’une d’elles a échoué, et un état explicite de ce qu’il n’a pas vérifié.
Ce comportement, décrit sur la page produit de Remy, suit un ordre immuable. Après avoir modifié le code, Remy lance les tests, la vérification de types ou la compilation concernés. Si quelque chose échoue, il cherche la cause, la corrige et relance la même vérification, pas une autre, plus facile. La page produit énonce sans détour la dernière étape : « Ensuite, il vous dit ce qui a été exécuté, avec quel résultat, et ce qu’il n’a pas vérifié. »
- Lancer les vérificationsTests, vérification de types ou compilation
- Trouver la causeQuand une vérification échoue
- Corriger et relancerLa même vérification, à nouveau
- Rendre compteCe qui a été exécuté, avec quel résultat, ce qui n’a pas été vérifié
C’est la vérification qui a échoué qui est relancée
Pourquoi relancer la même vérification compte
Tout l’intérêt tient à cette insistance à relancer la vérification identique. Une correction suivie d’un autre test, ou d’aucun test, ne permet pas de savoir si l’échec initial a disparu. Relancer la vérification qui a échoué relie la correction à la preuve qu’elle a fonctionné, et place cette preuve sous les yeux de la personne qui relit.
« Ensuite, il vous dit ce qui a été exécuté, avec quel résultat, et ce qu’il n’a pas vérifié. »
Dire ce qui n’a pas été vérifié
La dernière partie du rapport est peut-être la moins courante parmi les outils de programmation. La note finale de Remy sépare ce qui a été vérifié de ce qui ne l’a pas été ; dans la démonstration du produit lui-même, une tâche se termine par deux listes, l’une intitulée « Vérifié », l’autre « Non vérifié ». Une modification d’un code qu’aucun test ne couvre, par exemple, serait signalée comme non vérifiée au lieu d’être passée sous silence.
Une relecture avant la fusion
La vérification n’est qu’une couche. La documentation de Remy décrit un mode de revue de code distinct qui présente les constats par gravité, chacun avec son emplacement, son impact et les éléments qui l’étayent. Dans le flux de travail présenté sur la page produit, un bot de revue, Bugbot, lit le diff et cherche ce que les tests ont manqué avant que la pull request ne parte.
Corepass compte « Garder le travail relisible » parmi les principes qui guident sa conception, et le rapport de vérification en est l’expression la plus nette dans le produit : l’agent fait les vérifications, et le développeur obtient le relevé dont il a besoin pour décider de fusionner ou non.