Je vis actuellement le cas de la revue par une seule personne. C’est une mauvaise pratique. D’une part ça créé un goulot d’étranglement : le processus va être ralenti dans son ensemble par le fait que tout doit passer par un point unique. Comme une autoroute qui aurait une seule voie au péage. Même si le trafic n’est pas très important, ça va créer des ralentissements au niveau du péage et donc une perte de temps au final.
D’autre part, le pauvre lead dev va se farcir tout le code à relire. Il faut reconnaître que relire du code ce n’est pas le plus passionnant et il risque de vite se trouver lassé de devoir mettre en pause une fonctionnalité en cours de dev pour aller lire un pavé de code. Ce qui va accentuer le côté goulot d’étranglement et pourrait créer un ressenti de la part de l’équipe.
Un avantage du code review par les pairs, qui n’a pas encore été pointé je crois : cela aide à créer une responsabilité partagée du produit. Si tout le monde a la a responsabilité de produire une bonne architecture et de valider celle des autres, tout le monde est impliqué dans le fait d’avoir un produit bien conçu, même les débutants. Il est trop facile sinon de faire vite pour finir sa fonctionnalité en sachant qu’on est sécurisé car c’est la responsabilité du lead dev de dire s’il y voit un problème.
