|
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. ObjectifsLa révision de code vise plusieurs objectifs :
Hewlett-Packard valorise le retour sur investissement d'une revue de code à 10 pour 1[2]. Revue et testsLa 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]. PratiquesLa 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 formelleMichael 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 emailLe 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'épauleL'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ômeL'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éIl existe des logiciels permettant d'assister la revue de code[7]:
Quelques logiciels libres:
Analyse statiqueL'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 codageChecklistUne 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 :
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]. AutorelectureL'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 :
Cette étude indique privilégier l'hypothèse optimiste[14]. Intégration continueL'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 êtreL'é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étriquesLes métriques permettent de mesurer l'efficacité de la revue. Métriques possibles[16] :
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] :
Références
|
