Nous utilisons principalement deux formats de revue de code dans nos projets : la revue collective, plutôt formelle et la revue par un pair, un format plus léger. Les deux présentent des avantages et des inconvénients : revenons ensemble sur ces formats et comment les mettre en place dans une équipe.

Mais commençons par le commencement : qu'est-ce qu'une revue de code et quels bénéfices apporte-t-elle ?

Dans la plupart des domaines impliquant l’écriture, on n’imagine pas que ce qui est écrit soit publié sans avoir été relu. Un article sera toujours relu avant publication (par exemple celui que vous êtes en train de lire), que ça soit pour une vérification sur le fond - le sujet de l’article est-il bien traité ? - ou sur la forme - orthographe, grammaire, structure et lisibilité du texte. De la même manière, la pratique de la revue de code consiste à faire relire son code afin d’y trouver le maximum de défauts, que ça soit sur le fond - est-ce que ce code fonctionne, et matérialise bien la fonctionnalité prévue ? - ou sur la forme - clarté, lisibilité, respect des standards, etc.

Et chez vous, combien de lignes de code mettez vous en production sans qu’elles aient été relues ?

La revue de code est une pratique [presque aussi ancienne que le développement de logiciel](assets/ibmfagan.pdf "M.E., Fagan (1976). "Design and Code inspections to reduce errors in program development". IBM Systems Journal"), et très répandue chez des entreprises comme Microsoft ou Google. Il y a une bonne raison à cela, c’est qu’elle permet de détecter les défauts plus tôt dans le processus de développement.

Pourtant cette pratique est relativement peu répandue dans les équipes que nous rencontrons. C’est parfois parce qu’elle est méconnue, mais c’est plus souvent pour de mauvaises raisons : “On n’a pas le temps, ça coûte trop cher.” “On a essayé mais ça a tourné au troll.” Ou encore “Je ne veux pas le faire, c’est du flicage.”

Il semble donc que ça ne soit pas une pratique si simple à mettre en place !

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

Détecter les défauts au plus tôt

L’objectif principal de la revue de code est le même que les autres méthodes d’assurance de la qualité du logiciel : il s’agit de trouver au plus tôt les défauts qui existent dans le code. Les bénéfices de la revue de code ne sont plus à démontrer : selon [des études regroupées par Capers Jones](http://doi.ieeecomputersociety.org/10.1109/MC.2009.118 " Capers Jones, Christof Ebert (April 2009). "Embedded Software: Facts, Figures, and Future". IEEE Computer Society.") sur plus de 12 000 projets, la revue de code collective permet de détecter en moyenne 65% des défauts, 50% pour la revue par un pair, tandis que les tests n’en détectent en moyenne que 30%.

Attention, on ne dit pas qu’il faut abandonner d’autres pratiques d’assurance de la qualité : c’est une pratique indispensable à combiner avec d’autres pratiques, comme les tests, afin de maximiser la qualité du produit avant de le proposer aux utilisateurs.

Il existe d’autres bénéfices à la revue de code :

• Améliorer la qualité intrinsèque du logiciel et faire évoluer les standards.
• Propriété collective du code : faire relire le code par une autre personne que son auteur contribue à renforcer la propriété collective du code, et réduire le risque d’une spécialisation trop forte où seul l’auteur du code est capable de le modifier.
• Apprentissage : la revue de code est un moyen de former les plus jeunes en partageant les standards en place, en leur montrant certaines techniques, ou comment certaines fonctionnalités sont implémentées. C’est aussi l’occasion pour ceux qui sont arrivés plus récemment d’apporter un point de vue différent et proposer de nouvelles approches.
• Améliorer la qualité des échanges entre les développeurs.

Tous ces éléments font de la revue de code une pratique collective indispensable qui contribue à diffuser une culture de la qualité au sein de l’équipe.

Revue de code collective

La revue de code collective consiste à organiser des sessions d’inspection formelles, régulières et en groupe, dédiées à la détection de défauts.

Nous proposons le format suivant :

• Temps et périmètre limité
  • Séance d’1h30 maximum, une fois toutes les deux semaines.
  • Viser un taux de revue de 300 lignes de code par heure.
  • Consacrer plus de temps ou essayer de relire plus de code en une seule session nuit à la qualité de la revue.
• Dédiée à la détection des défauts : la séance est dédiée uniquement à relever les défauts, pas à les corriger en séance, ni à débattre des questions de standards ou de design : on consacre une minute maximum à chaque défaut.
• Statut et suivi : en fin de revue, on décide si le code revu est acceptée ou rejeté. Le cas échéant, les défauts retenus à l’issue de la revue sont enregistrés et leur correction est vérifiée.
• Participants
  • L’auteur du code est présent, ainsi que plusieurs relecteurs.
  • Afin de faciliter le déroulement,on désigne :
    • un modérateur, qui garantit qu’on se concentre sur la découverte des défauts, et que les échanges sont de qualité.
    • un scribe, qui note les défauts relevés.
    • un gardien du temps.
• Préparée : le code à relire est sélectionné et communiqué à l’avance, afin que les relecteurs puissent relire le code à tête reposée.
• Outillée : on construit progressivement des checklists afin de faciliter le déroulement de la revue.

Comment sélectionner le code ?

• Dans l’optique de détecter les nouveaux défauts introduits, on sélectionne le code ajouté ou modifié pour réaliser les dernières fonctionnalités.
  • On relit idéalement tout le code produit récemment, mais ce n’est faisable que si l’équipe est suffisamment petite.
  • Sinon, on sélectionne dans le code récemment modifié une partie sensible, complexe, ou qui introduit de nouveaux concepts, un nouveau pan de l’architecture logicielle, etc.
• On peut aussi sélectionner du code existant qui fait “peur”, complexe, sujet à des régressions fréquentes, par exemple si on sait qu’on va devoir le faire évoluer prochainement.

Revue par un pair

La revue par un pair consiste à ajouter une étape dans le processus de développement. C’est une pratique plus largement répandue car plus simple, moins contraignante à mettre en place. Il existe plusieurs variantes de ce type de revue, allant du pair programming à un format proche de la revue collective, hormis le fait que la revue est faite par un seul autre développeur.

Voici un format que nous avons utilisé avec succès sur plusieurs projets :

• Points communs avec la revue collective
  • Dédiée à la détection des défauts et non aux corrections.
  • Préparée.
  • Statut et Suivi.
• En binôme
  • Afin d’obtenir des bénéfices similaires à ceux d’une revue collective, la revue occasionne un échange entre l’auteur du code et le relecteur.
  • Lors de la revue, une fois que l'auteur a présenté le code pour partager l'intention du code revu, c’est le relecteur qui navigue dans le code.
• Périmètre limité à une fonctionnalité : dès que le développement d’une fonctionnalité, d’une User Story, est considéré comme terminé par le développeur, une revue est déclenchée sur ce code.
• Systématique : la revue est systématique et obligatoire pour tout code destiné à arriver en production.
• Outillée :
  • Le code revu est directement lié à un ou plusieurs commits, on utilise généralement le différentiel des modifications comme support.
  • On utilise souvent un outil plus avancé pour tracer le suivi des défauts, des outils comme Gerrit, ou Github directement.
  • Sur certains projets, nous avons aussi simplement attaché la liste des défauts à la User Story associée sur le board.

Qui fait la revue de code ?

Idéalement, la première personne disponible s’occupe de la revue. Tout comme dans la version collective, il faut éviter que ça soit toujours la même personne qui s’occupe des revues, pour favoriser la propriété collective du code.

C’est une étape obligatoire dans votre processus de développement, affichez-la sous forme d’une nouvelle colonne sur votre board avant l’étape de revue fonctionnelle.

Que faire des défauts relevés lors de la revue ?

Pour être efficace, une revue de code doit être dédiée à relever les défauts, et la correction ou les éventuelles discussions ont lieu séparément :

• Lorsque la correction à appliquer est claire et ne fait pas débat (défaut fonctionnel, écart à un standard établi), l’auteur du code réalise la correction après la revue et un suivi est effectué pour s’assurer que les défauts ont bien été corrigés.
• Souvent, deux approches d'implémentation peuvent se valoir. Dans le cas d’une revue en binôme, il sera utile de faire appel à un tiers ou toute l’équipe pour faciliter la prise de décision.
• Lorsque le point d’attention concerne un standard non établi, on fait évoluer les standards écrits de l'équipe, en s’assurant qu’ils soient partagés par tous.

Il est courant que certains points plus complexes nécessitent un échange avec toute l’équipe :

• on peut réserver une demi heure en fin de revue collective, ou solliciter l’équipe pour un point dédié dans le cas de la revue par un pair.
• sur plusieurs projets, nous avons également ritualisé un créneau d’une ou deux heures en fin d’itération, appelé selon les équipes “l’heure Tech” ou le Dojo, au cours duquel on peut aborder ces points.

Revue collective ou par un pair ?

Le tableau ci-dessous donne quelques critères (non exhaustifs) de comparaison entre les deux formes de revue de code présentées :

Les différentes études évoquées dans Best Kept Secrets of Peer Code Review et les chapitres sur la qualité logicielle et les pratiques de construction collaborative dans Code Complete montrent que la revue collective est globalement plus efficace que la revue par un pair, mais présente l’inconvénient d’être plus lourde et coûteuse à mettre en oeuvre.

Ces études montrent également que la très grande majorité des défauts sont relevés lors de la relecture en préparation de la revue. Ceci nous conforte dans l'utilisation de la revue par un pair, à condition qu'elle soit bien préparée : elle permet d'obtenir un bon compromis en évitant le coût d'une réunion avec de nombreux participants.

On peut aussi utiliser les revues de code collectives formelles en complément des revues en paires :

• en format court restreint aux points qui ne sont pas évidents, non couverts par les standards.
• sur certains algorithmes ou éléments de design complexes.
• pendant le période de mise en place des revues, afin que l'équipe se forme collectivement à la pratique.

Que conclure ?

On trouve de nombreux articles suivant le schéma  “Les [avantages|dangers] du [Code|Pair Review|Pair Programming]”, mais au final, le débat n’est pas là. Même si nous émettons un avis plus en faveur d'un format, peu importe que vous fassiez du Pair Programming, de la Revue collective ou par un pair : l’essentiel est de trouver l’approche qui correspond à la culture de votre équipe.

Cet article propose une analyse intéressante du sujet et nous reprendrons sa conclusion ici : analysez et admettez les faiblesses dans vos pratiques de développement collaboratives. Si vous n’avez pas encore choisi une approche, échangez avec des développeurs pour qui ces pratiques sont régulières.  Expérimentez et cherchez à vous améliorer, lors d’une rétrospective par exemple...

Nous avons jusqu’ici décrit des formats de revue de code : au travers du prochain article, nous partagerons avec vous les écueils rencontrés qui ont pu mettre cette pratique en péril.