Récemment, chaque fois que j'ouvre l'onglet PR, je me sens un peu épuisé. Les PR s'accumulent, l'IA génère du code en continu, et le nombre de reviewers ne change pas d'un iota. On a l'impression que la vitesse du tapis roulant dépasse largement la capacité réelle de l'équipe à suivre. La revue devient une course pour rattraper cette vitesse. Dès que le test passe, le code est fusionné. Les conséquences en production seront traitées plus tard.

Mais le problème majeur ne réside pas dans la quantité, mais dans le mécanisme d'incitation. Les développeurs peuvent livrer du code semi-fini sans presque aucune conséquence. Et les reviewers passent du temps supplémentaire à repérer des bugs subtils, mais ne reçoivent que plus de travail, voire sont parfois considérés comme « ralentissant le progrès ». Ce système repose sur la bonne foi, alors que le comportement réel est dicté par les échéances et les KPI. Cet écart se reflète finalement dans la qualité du code.
C'est pourquoi je trouve ce que @mergeproofapp construit est très intéressant. Ils ne se contentent pas d'appeler à une plus grande attention à la qualité du code, mais donnent une valeur économique aux PR. Pour fusionner du code, il faut miser des tokens. Si vous croyez que votre code est suffisamment fiable, soutenez-le avec des tokens. Si quelqu'un trouve un bug efficace, il recevra une récompense. La mécanique précise est détaillée dans , mais le principe de base est simple : un code de haute qualité doit prendre des risques correspondants.
Lorsque les développeurs ont un intérêt réel dans les PR, ils réfléchissent davantage avant de soumettre. Lorsque les reviewers ou chasseurs de bugs peuvent obtenir des gains évidents, ils liront plus attentivement. Les propriétaires de projets peuvent mettre en place des bounties pour protéger activement leur dépôt de code, plutôt que de compter uniquement sur la bonne volonté des développeurs.
Si le mécanisme d'incitation ne change pas, la qualité du code ne s'améliorera pas non plus. Bien que faire supporter une responsabilité économique aux submitters puisse sembler inconfortable, cela forcera chacun à prendre plus au sérieux le code qu'ils soumettent.