Logo Spiria

La revue de code, tout simplement

20 novembre 2015.

Quel que soit le projet, un des outils fondamentaux dans le développement de logiciels est la revue du code. Chose surprenante, personne ne semble vraiment savoir pourquoi les revues de code sont importantes. Plusieurs s’y résignent simplement parce qu’il s’agit d’une autre étape du processus.

Pourquoi, au juste ?

Personnellement, j’aime bien connaître les raisons pour lesquelles je fais quelque chose. S’il n’y a pas de raison valable ou d’explication logique justifiant qu’une opération soit effectuée, c’est avec grand plaisir que je propose que celle-ci soit écartée du processus. Si elle n’a aucune utilité, il s’agit d’une perte de temps et d’énergie.

Raison no 1 – Identifier les bogues

Tout le monde s’entend pour dire qu’un bogue qui est identifié pendant le processus de développement est infiniment moins coûteux que celui qui serait identifié pendant l’AQ, le UAT ou, pire encore, durant la production. Une revue du code correctement menée aidera à identifier des choses qui, si elles sont réglées au bon moment, feront économiser énormément de temps, d’argent et d’énergie.

Exemples

  • Erreurs d’inattention ou de frappe ;
  • Des cas d’utilisation manquants ou oubliés ;
  • Les erreurs d’implantation les plus difficiles à déceler : débordement de tampon (buffer overflow), les faiblesses au niveau de la sécurité, threading, etc.

Raison no 2 – Le partage des connaissances

Au sein d’une équipe de programmation, nous ne pouvons pas tous atteindre le niveau d’excellence d’un [insérez ici le nom de votre sportif favori] dans toutes les facettes du logiciel. Nous avons tous nos champs d’expertise, nos petits plaisirs et notre jardin secret de l’excellence. Cependant, pour se développer en tant qu’équipe, il faut quitter notre zone de confort et observer ce que font les autres : s’inspirer d’eux et de leur code.

Une revue du code est une excellente façon de partager des connaissances. Nos collègues pourront jeter un coup d’œil à certaines parties du projet sur lequel il n’auraient autrement pas travaillé, apprendre quelques nouveaux trucs du métier et éventuellement amener leurs connaissances techniques et leur savoir-faire à un autre niveau, les rapprochant encore de l’excellence.

Il s’agit également d’une excellente façon de prévenir le « syndrome du vacancier », où un projet entier fait du surplace, puisque la seule personne qui comprend comment le module Omega fonctionne est malheureusement en vacances et que personne ne veut s’y atteler. Personnellement, ayant déjà eu à interrompre mes vacances d’urgence pour régler un bogue, j’aime que mes vacances soient ininterrompues.

Raison no 3 – Continuité

De nouvelles technologies, de nouvelles pratiques, de nouvelles normes de codage et de nouveaux patrons de conception sont inventés tous les jours et sont théoriquement bons à apprendre et à intégrer dans un projet de logiciel. À l’intérieur même du cycle de vie d’un projet, on devrait favoriser l’homogénéité, afin que son étendue reste sous contrôle.

La revue du code est le dernier rempart contre une entropie logicielle débridée. L’adoption d’une nouveauté, que ce soit un standard, une pratique ou une technologie, devrait être le fait de toute l’équipe et non l’œuvre d’un développeur seul, ni une décision prise pour le simple plaisir d’expérimenter.

Étiquette

Il y a une étiquette à la revue de code, de façon à ce que l’exercice reste un plaisir pour tous, indépendamment de l’outil utilisé. Au cas où vous vous le demanderiez, il y a une foule d’outils disponibles pour la revue de code, mais il y a là matière à un autre article.

Règle d’étiquette no 1 – L’objectivité

Votre équipe a sans doute des normes de codage, incluant un style de codage prédéterminé, un ensemble de bonnes pratiques, etc.

Rien n’est plus frustrant que de recevoir des commentaires subjectifs, teintés des goûts du réviseur en matière de style de codage, de pratiques ou de styles, en lieu et place de ceux de l’équipe.

Un exemple de commentaire subjectif : « Ces 5 lignes de code pourraient être réécrites en une seule ligne grâce au chaînage (chaining). »

Ce commentaire est totalement subjectif, deux programmeurs ne s’entendront pas à savoir laquelle de ces deux formes est la meilleure. En tant que réviseur, votre devoir est de contrôler l’envie d’imposer vos préférences personnelles ou votre style dans un champ qui est controversé. Si vous (ou votre alter ego) en ressentez le besoin, demandez à ce que l’équipe se rassemble dans une salle, exposez votre problématique, assurez-vous qu’il y a bien un problème, puis faites un brainstorm jusqu’à trouver une solution. Il ne vous reste plus qu’à en débattre les mérites (il peut y avoir des tensions, c’est un danger inhérent aux réunions après tout) et prenez une décision en équipe. La décision ne sera peut-être pas conforme à vos préférences personnelles, mais il s’agira au moins d’une décision de l’équipe, ce qui est infiniment mieux que l’autre option (c.-à-d. : d’éternelles prises de bec).

Règles d’étiquette no 2 – Donner de bonnes rétroactions

Lorsque vous voyez quelque chose de soigné et de bien fait, mentionnez-le dans la revue de code ; tout le monde aime être reconnu pour son bon travail.

Une autre possibilité est de mentionner dans la revue les choses qui pourraient être améliorées ou faites plus efficacement, en expliquant comment et pourquoi le travail laisse à désirer, puis discutez avec la personne que vous révisez pour trouver une autre conception ou une solution de rechange. L’objectif n’est pas de corriger le code à la place des codeurs, mais de leur donner suffisamment d’information pour qu’ils puissent améliorer eux-mêmes le code et apprendre de leur expérience (et par la même occasion, de vous !).

En terminant, soyez avertis que la solution préconisée ne sera peut-être pas exactement ce que vous auriez vous-mêmes fait, ne vous en faites pas ; tant et aussi longtemps que les besoins de l’entreprise et les standards de l’équipe sont respectés, tout ira bien.

Étude de cas :

Vous voyez une revue de code incluant une unité de test qui mentionne systématiquement le service d’URL-shortening bitly.com.

Mauvaise rétroaction :

« C’est mauvais, ça ne devrait pas faire partie des tests unitaires. »

Bonne rétroaction :

« Ce test va échouer :

  • si le service n’est pas disponible ;
  • si le quota journalier n’est pas dépassé ;
  • si l’API est changé ou si la clé API expire ;
  • si les serveurs sont hors service. »

« Si nous avions utilisé la bibliothèque de « mocking » pour simuler l’ensemble des demandes à ce service, alors notre test serait à toute épreuve. »

« De plus, si nous devons procéder à des tests sur l’intégration de Bitly, ce devrait être ajouté au Test Suite d’intégration. »

Règle d’étiquette #3 – Partagez vos histoires

Nous avons tous nos propres expériences dans le contexte de différents projets et avec des technologies diverses ; des expériences particulièrement intéressantes peuvent être partagées dans le cadre d’une revue de code, tout en animant la conversation. En bonus : tout le monde profite d’une excellente histoire !

Étude de cas :

Vous voyez une revue de code avec un test unitaire qui ouvre un thread, tombe en veille pendant 3 secondes, puis vérifie les résultats du thread.

Voilà mon histoire :

« Dans un projet passé, nous avions des tests de ce genre et nous avons eu notre lot de faux échecs lorsque la machine était particulièrement lente, ce qui a complètement miné notre confiance en notre Test Suite. Après cela, nous avons retravaillé notre suite pour être aussi déterministe que possible et pour que les résultats ne dépendent pas de la vitesse de la machine. »

Pour terminer

Lorsque l’équipe révise correctement le code, elle crée de meilleurs logiciels, avec moins de bogues (peut-être même aucun ?) et tous évoluent à la fois en tant qu’individu et en tant qu’équipe.