Voici un nouvel épisode qui clôt notre série sur le thème de la revue de code, et plus précisément sur les écueils que nous avons rencontrés et qui risquent de rendre difficiles le bon déroulement de vos revues.

Cet article fait partie de la série :

• Revue de code : quel format choisir ?
• Comment rater vos revues de code ?
  • Episode 01
  • Episode 02
  • Episode 03

Le Tech Lead passe tout son temps à faire de la revue

On rencontre souvent des équipes où seules les personnes les plus expérimentées de l’équipe, voire uniquement le Tech Lead, sont habilitées à revoir le code de l’équipe.

Il arrive également dans certains cas que la revue soit faite seulement par des experts extérieurs à l’équipe. Ou encore que certains membres de l’équipe ne se sentent pas légitimes pour faire de la revue de code, car ils viennent d’arriver ou ne seraient pas assez expérimentés.

Réserver la revue aux personnes les plus compétentes devrait théoriquement permettre de s’assurer qu’un maximum de défauts soient détectés, et pallier certains problèmes évoqués depuis le début de cet article.

Mais cette problématique de confiance dans la participation de tous à la revue de code peut avoir deux effets indésirables :

• n’ayant pas confiance pour déléguer, le Tech Lead se retrouve surchargé et passe son temps à faire de la revue plutôt que d’aider son équipe au quotidien.
• le Tech Lead étant le seul officiellement à relire et valider le code des autres développeurs, on perd les bénéfices de transmission du savoir et de propriété collective du code.

Restreindre les “droits de revue” peut avoir du sens dans certains cas. C’est une approche assez utilisée sur des projets open source, dans lesquels sont constitués des groupes de committers, seuls habilités à intégrer des contributions et donc à revoir le code. Mais nous sommes convaincus que lorsqu’on a une équipe de développement identifiée, colocalisée, cette approche ne devrait pas être utilisée sur le long terme.

L’objectif devrait être de parvenir à une équipe autonome et responsabilisée, où chacun participe à la revue de code. Nous croyons à une approche en cercle de qualité plutôt que chirurgicale avec un expert entouré de ses assistants.

Voici quelques pistes pour aller vers un fonctionnement plus efficace :

• Si toute l’équipe n’est pas à l’aise pour faire de la revue, il est préférable de commencer par organiser des revues collectives plutôt qu’en binôme, en s’assurant d’embarquer les moins expérimentés pour les faire progresser.
• Si on utilise la revue en binôme, on décide collectivement ou avec le Tech Lead de qui est le plus pertinent pour faire cette revue, quitte à monter parfois un trinôme de revue.
• Faire revoir son code par un développeur moins expérimentée n’est pas forcément risqué : il trouvera certains défauts par lui même, posera des questions qui amèneront à détecter les défauts avec l’auteur. Il proposera peut être aussi de nouvelles façons de faire.

Ça fait mal quand on critique mon code

Lors d’une séance de coaching : “Alors, comment s’est passée votre dernière revue ?”

Xavier : “Assez tendue… ça a clashé entre Etienne et Vincent.“

Moi : “Pourquoi ?”

Xavier : “Etienne présentait le code qu’il a produit sur la User Story #135, et Vincent lui a dit « C’est de la merde ton implem’ ! ». Du coup, tu connais Etienne, il s’est braqué et n’a plus rien dit jusqu’à la fin.”

Damien Beaufils

Par essence, la revue de code comporte une problématique humaine : il s’agit de faire relire la production d’une personne par ses pairs et d’en faire une critique. Certaines sessions se passent mal lorsque le relecteur pointe l’auteur du code plutôt que les défauts relevés, ou que l’auteur prend les critiques du code comme une attaque personnelle. Cela devient particulièrement difficile à animer sur une session collective car certaines personnes risquent de se braquer et refuser la revue.

Un point essentiel dans la revue de code, et plus largement dans les pratiques collectives de développement est de donner un feedback de qualité à ses pairs. Notamment, il s’agit de dissocier le code et la personne qui l’a écrit, dans ses formulations mais aussi dans la réception du feedback. Le manifeste Egoless programming (The Ten Commandments of Egoless Programming) présente très bien ces principes :

• n’hésitez pas à l’afficher et vous y référer dès que ce type de problème se produit.
• c’est aussi le rôle du modérateur de s’assurer de la qualité des échanges lors des sessions collectives.

S’il n’y avait qu’une seule phrase à retenir sur ce point :

Soyez doux avec les développeurs, pas avec le code.

Je n’ai pas de soutien du management

J’ai accompagné une équipe qui a mis en place la revue de code collective. Le manager a d’ailleurs décidé que des sanctions seraient prises à partir de quatre défauts trouvés dans une revue.

Et là, le miracle s’est produit : les revues de code n’ont jamais détecté plus de quatre défauts !

Gérald M. Weinberg

On a vu jusqu’ici plusieurs écueils qui peuvent réduire l’efficacité de la revue de code, au risque de se traduire par un manque d’adhésion de l’équipe.

Mais en plus de tout cela, un élément de taille est à considérer : avez-vous le soutien du management ? Mieux, est-il prêt à s’engager pour faire réussir la démarche ?

Un problème courant est de voir le management ou par exemple le Product Owner de l’équipe demander à ne pas faire la revue de code sur un sujet parce qu’on n’a “pas le temps”, que le sujet est urgent.

Il est indispensable que tous les intervenants de l’équipe soient alignés sur les enjeux, et surtout les bénéfices attendus de la revue. Pour convaincre des personnes non techniques, n’hésitez pas :

• à vous appuyer sur des éléments concrets, comme les études citées dans notre premier article

• à mesurer l’efficacité des revues. Pour cela, sans rentrer dans le détail, le meilleur indicateur que nous utilisons est de mesurer le nombre de bugs détectés en fonction de l’étape de réalisation : admettant que plus un défaut est détecté tard plus il coûte cher à corriger, on souhaite alors maximiser la part des défauts détectés au plus tard lors de la revue de code.

Attention néanmoins au risque inverse : le management doit être convaincu, mais ne doit pas pour autant s’immiscer dans le processus de revue au risque qu’elle soit perçue comme du “flicage”.

Cette approche qu’on a vu dans l’anecdote de Christophe comporte une erreur dans l’objectif : il s’agit de trouver un maximum de défauts pour améliorer la qualité du code, et surtout pas de trouver les personnes qui introduisent des défauts. Nous en introduisons tous car nous faisons tous des erreurs. Il vaut mieux s’inquiéter si les revues ne trouvent pas de défauts !

Il ne faut pas confondre efficacité et efficience : mesurer le nombre de défauts trouvés en revue, le rapport au nombre de lignes de code examinées est intéressant pour étudier si le processus de revue de code est optimale, mais ne donne en aucun cas un indicateur sur son efficacité au global.

Une règle essentielle pour éviter ce type d’écueil : la revue de code est une pratique technique. Donc, seules les personnes compétentes techniquement doivent y participer, les animer et suivre les corrections.

Alors, finalement, comment réussir vos revues ?

On le répète,  le premier point à retenir : soyez vigilants en organisant vos premières sessions de revue. Si elles se passent mal dès le début et que vous ne résolvez pas rapidement les problèmes, vous vous tirez une balle dans le pied. La pratique risque alors d’être abandonnée ou déformée.

Pour conclure cette série d'article sur la revue de code, voici en synthèse les points que nous pensons importants pour réussir vos revues de code :

• Assurez vous d’obtenir un soutien fort du management.

• Faites de la revue de code une pratique collective, où tout les membres de l'équipe participent.

• Si les revues sont douloureuses pour des raisons d’ego, n’hésitez pas à vous faire accompagner par un intervenant neutre, un facilitateur, afin de désamorcer les situations tendues.

• Si votre équipe est novice avec la revue de code, commencez par vous former et privilégiez des sessions collectives, au moins dans un premier temps.

• Formalisez votre processus de revue de code et veillez à le respecter : comment doit-elle se dérouler ? quand ? avec quels supports ?

• Faites évoluer votre pratique de la revue au cours de vos rétrospectives.

• Appuyez-vous sur des standards que vous faites évoluer et constituez des checklists. Automatisez ce qui peut l'être.

Et toujours, n’hésitez pas à partager vos retours d’expérience via les commentaires, qu’ils se soient bien ou mal passés !

Merci aux OCTOs de la tribu Software Craftsmanship pour leurs précieuses contributions.