Revue de code
La revue de code (calque de l'anglais code review), ou révision de code[1], est l'examen systématique du code source d'un logiciel.
Cet examen peut être comparé à la critique effectuée par un comité de lecture, dont le but est de trouver des bugs ou des vulnérabilités potentielles ou de corriger des erreurs de conception afin d'améliorer la qualité, la maintenabilité et la sécurité du logiciel.
Une revue de code peut s'appuyer sur la vérification (manuelle ou automatisée) du respect d'un ensemble de règles de programmation.
Si la revue de code est depuis longtemps reconnue comme un moyen performant d'améliorer la qualité du logiciel, les organisations qui ont mis en place cette démarche systématique ont longtemps été minoritaires[2]. La revue de code tend à devenir une étape à part entière dans le développement logiciel, en particulier dans les méthodes agiles comme l'extreme programming.
Objectifs[modifier | modifier le code]
La révision de code vise plusieurs objectifs :
- améliorer la qualité du code [3] ;
- favoriser la collaboration, le travail en équipe[3] (appropriation du code par l’équipe) ;
- appliquer un standard [3] ;
- détecter et corriger les défauts (bugs mais aussi lisibilité) au plus tôt dans le cycle de vie du code pour économiser les coûts[4] ;
- former des développeurs.
Hewlett-Packard valorise le retour sur investissement d'une revue de code à 10 pour 1[2].
Revue et tests[modifier | modifier le 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].
Pratiques[modifier | modifier le code]
La revue de code peut prendre différentes formes, plus ou moins formelles. Il faut choisir le modèle le mieux adapté en fonction de la tolérance au risque du code audité[2].
Inspection formelle[modifier | modifier le code]
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].
Notification par email[modifier | modifier le code]
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]
Analyse par-dessus l'épaule[modifier | modifier le code]
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].
Programmation en binôme[modifier | modifier le code]
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].
Utilisation d'un outil dédié[modifier | modifier le code]
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.
Analyse statique[modifier | modifier le code]
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.
Définition de règles de codage[modifier | modifier le code]
Checklist[modifier | modifier le 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].
Autorelecture[modifier | modifier le code]
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].
Intégration continue[modifier | modifier le code]
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].
Savoir être[modifier | modifier le code]
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].
Métriques[modifier | modifier le code]
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
Références[modifier | modifier le code]
- « revue de code », Grand Dictionnaire terminologique, Office québécois de la langue française (consulté le ).
- Seven Truths About Peer Reviews Karl E. Wiegers.
- Revue de code pour les équipes trop occupées, Alexandre Alquier 27 juillet 2010
- Revue de code, Peer Code review, Marc Collin
- Code Reviews: Just Do It Jeff Atwood 21 janvier 2006
- Design and Code Inspections to Reduce Errors in Program Development M.Fagan, IBM Systems Journal, Vol. 15, No. 3 (1976), p. 182-211
- Lightweight Code Review Episode 2: Why Code Inspections Fail, Jason Cohen
- Software Inspection Tom Gilb et Dorothy Graham 1993, (ISBN 0201631814)
- Lightweight Code Review Episode 3: Pros and Cons of Four Kinds of Code Review, Jason Cohen
- Lightweight Code Review Episode 6: Checklists - You build me up just to knock me down, Jason Cohen
- Trousse pour une revue personnelle, version 1
- Lightweight Code Review Episode 4: The Largest Case Study of Code Review, Ever Jason Cohen
- The Importance of First Impressions: How Theatre Criticism Might Inform Peer Code Review Mike Conley 7 février 2010
- SmartBear study at Cisco, p. 4. "We took a random sample of 300 reviews to investigate, and the evidence definitively showed that the reviewers were indeed carefully reviewing the code – there were just fewer bugs."
- Pair Programming vs. Code Reviews, Jeff Atwood 18 novembre 2007
- Do Your Inspections Work? Karl Wiegers
