Revue de code

La revue est environ 2 à 4 fois plus rapide que le test[2] et offre un meilleur taux de détection des défauts : tests unitaires 25 %, tests d'intégration 45 %, revue de conception 55 %, revue de code 60 %[5].

Mais la revue ne détecte pas les mêmes défauts que le test[2].

Michael Fagan, cadre chez IBM, a formalisé en 1976 une méthode d'inspection du code qui se base sur la convocation de plusieurs réunions d'audit [6]. Assez lourde, elle requiert en moyenne neuf heures-hommes pour 200 lignes de codes[7], elle est difficile à systématiser pour l'ensemble du code.

Tom Gilb et Dorothy Graham ont développé une autre méthode d'inspection assez répandue également[8].

Le système de gestion de versions peut être configuré pour envoyer un email décrivant chacune des modifications apportées à l'arborescence des sources. Les autres développeurs de l'équipe ont alors l'opportunité d'examiner ces changements.

Cette méthode pose des problèmes d'assurance qualité : comment savoir si une modification a bien été revue, si les critiques ont été prises en compte…[7]

L'analyse par-dessus l'épaule (over the shoulder review) est une méthode informelle : l'auteur du code pilote la revue en présentant au relecteur les modifications qu'il a effectuées dans le code source.

Elle a l'avantage d'être simple et rapide à réaliser. L'un de ses inconvénients est que, puisque c'est l'auteur qui pilote la revue, il peut manquer un effet de bord qu'il n'avait pas déjà remarqué au moment de l'écriture[9].

L'efficacité comparée de la programmation en binôme avec les autres méthodes de revue de code reste une question assez controversée. Il est par exemple possible que le binôme ne possède pas un recul suffisant sur le code[9].

Il existe des logiciels permettant d'assister la revue de code[7]:

• collecte et présentation des modifications apportées aux fichiers sources qui nécessitent une relecture
• gestion du workflow : la relecture devient une étape de l'intégration continue
• annotation des défauts et commentaires issus de la relecture, suivi des corrections de ces défauts
• statistiques et métriques (vitesse de relecture, taux de détection des défauts…)

Quelques logiciels libres:

• Review Board : logiciel libre à interface web créé par VMware.
• Agile Review : plugin libre pour Eclipse.
• Crew : logiciel libre de revue de code pour les projets Git.
• Rietveld : développé pour Google par Guido van Rossum.
• CodeStriker.
• JCR : Java Code Reviewer.

L'analyse statique de programmes est l'utilisation d'outil comme lint et ses successeurs pour vérifier le respect d'un ensemble de règles de programmation. L’analyse statique permet d'automatiser (systématiser) certains contrôles (complexité du code, respect de règles de codage…) mais ne permet pas de vérifier certains points plus abstraits (réutilisabilité, efficience, respect du cahier des charges…) qui nécessitent une relecture manuelle.

L'analyse statique et la revue par les pairs sont donc complémentaires, permettant d'étendre qualitativement et quantitativement la revue du code. L'outil d'analyse statique permet notamment de se décharger des vérifications de détails et favorise une vision plus globale du système étudié lors de la revue de code.

Une checklist est un document qui synthétise les points à vérifier prioritairement pendant la revue de code.

Une check-list ne devrait pas contenir plus de dix items, limite de ce qu'un humain normal peut mémoriser[10]. Il convient donc de :

• supprimer les questions triviales du type "le code est-il correctement commenté" ou "le code répond-il au besoin ?"[10]
• utiliser un outil d'analyse statique pour automatiser tout ce qui peut l'être (mise en page, convention de nommage…)[10]

Les items ne devraient concerner que des choses qui sont souvent oubliées : par exemple "vérifier que la méthode libère proprement les ressources pour tous les cas de retour d'erreur"[10]. On peut pour cela analyser les 100 ou 200 dernières corrections de bugs pour trouver les causes d'erreurs les plus fréquentes, en faire des items de check-list [10].

Il sera alors intéressant de classer les nouveaux bugs par items de check-list (en n'oubliant pas une catégorie "aucun de ces items"). Quand un item de la check-list ne contiendra presque plus de bugs (parce qu'une stratégie pour éviter ce problème aura émergé), il sera temps de remplacer cet item par la cause d'erreur la plus fréquente dans la catégorie "aucun de ces items"[10].

L'autorelecture ou revue personnelle du code consiste pour un développeur à utiliser des méthodes de la revue de code (notamment une check-list) sur sa production logicielle pour détecter et en corriger les défauts[11].

Une étude réalisée à Cisco a montré que les revues qui avaient été préparées par l'auteur (annotation des modifications réalisées dans le code source) retournaient beaucoup moins de défauts[12]. Deux hypothèses ont été avancées :

• pessimiste : les annotations induisent la relecture et stérilisent son effet[13]
• optimiste : pendant la phase de préparation, l'auteur est amené à relire son code et corrige de lui-même les principaux défauts

Cette étude indique privilégier l'hypothèse optimiste[14].

L'intégration continue peut systématiser une étape d'analyse statique et/ou de revue par les pairs pour tout nouveau code intégré [3].

L'équipe doit développer une culture de partage du code source, encourager les discussions sur le code. Les gens sont peu enclins à prendre du temps pour comprendre le fonctionnement d'un code trop complexe, donc les retours seront très généraux dans ce cas[15].

Il est difficile pour un salarié de dire à son chef qu'un de ses collègues a fait un mauvais travail[15]. Le management doit donc développer un climat favorable à la détection des défauts : les bugs sont un processus normal, pas une faute individuelle. Il convient de ne pas culpabiliser mais de mettre par exemple l'accent sur le travail d'équipe : ce qui compte c'est la qualité finale du logiciel.

Les développeurs doivent apprendre à maitriser leur égo, faire la distinction entre critique du code et critique personnelle. Il faut prendre en compte les personnes qui ne veulent pas montrer leur travail[2].

Il faut aussi convaincre la direction de l'intérêt d'allouer des ressources à la relecture[2].

Les métriques permettent de mesurer l'efficacité de la revue.

Métriques possibles[16] :

• nombre de lignes de code examinées
• nombre de défauts trouvés, leur criticité
• ressources (heure.homme consacrée à la revue, à sa préparation, au traitement des défauts)

Ce qui permet de calculer par exemple la densité de défaut par ligne de code, la vitesse moyenne d'inspection d'une ligne de code ou le temps de découverte d'un défaut.

Une mesure à large échelle menée chez Cisco a montré que[12] :

• limiter le nombre de lignes par revue : le nombre de défauts trouvés diminue fortement au-dessus d'un certain seuil. Chaque revue ne devrait concerner optimalement que 200 lignes, 400 au maximum
• vitesse limite de 400 à 500 lignes de code par heure
• une heure maximum par revue
• un relecteur trouve en moyenne quinze défauts par heure