Inspection et revue de code¶
La relecture du code par un autre développeur est le contrôle qualité le plus étudié du génie logiciel, depuis les inspections formelles d'IBM en 1976 jusqu'à la revue de PR moderne. C'est aussi le contrôle sur lequel reposent la plupart des orchestrateurs d'agents : « un humain relit avant fusion ». Ce chapitre rassemble ce que la recherche a mesuré de son efficacité réelle — qui est à la fois plus faible et plus diverse qu'on ne le croit.
Les inspections formelles (1976-1997)¶
Fagan chez IBM¶
Michael Fagan formalise en 1976 l'inspection : une réunion préparée, avec des rôles fixés (modérateur, lecteur, auteur, testeur), à des étapes définies du développement (IBM Systems Journal 15(3), scan). L'article contient les chiffres qui ont fait sa réputation :
- sur un projet de programmation système, un échantillon inspecté a 38 % de défauts en moins par millier de lignes qu'un échantillon relu de façon informelle, à test équivalent ; la productivité du codage augmente de 23 % ;
- environ deux tiers des défauts signalés pendant le développement sont trouvés par les inspections avant les tests sur machine ;
- le fameux 82 % d'efficacité de détection vient d'un seul petit programme COBOL de 4 439 instructions écrit par deux programmeurs chez l'assureur Aetna en 1975.
Fagan donne aussi la première règle de fatigue documentée : l'efficacité de détection des équipes « tend à diminuer après deux heures d'inspection » ; il recommande des séances de deux heures au plus, deux par jour.
Erreur fréquente : citer « 82 % » comme une moyenne
Le 82 % de Fagan est un cas unique et favorable. Le chiffre plus robuste de son article est celui des deux tiers, et Fagan précise lui-même que l'efficacité de chaque inspection prise séparément est inférieure.
Faut-il une réunion ?¶
L'équipe de Lawrence Votta et Adam Porter aux Bell Labs a démonté plusieurs éléments du rituel :
- Votta (FSE 1993), sur 50 inspections de conception industrielles : la réunion ne trouve qu'environ 5 % de défauts supplémentaires, quand Watts Humphrey en annonçait 25 % (chiffres rapportés par Porter et al. 1997) ;
- dans des expériences avec des étudiants (1995) et des professionnels (1996), les inspections sans réunion trouvent plus de défauts que celles avec réunion (page de Porter) ; la réunion sert surtout à éliminer les faux positifs.
L'expérience de 18 mois chez Lucent¶
Porter, Siy, Toman et Votta (IEEE TSE 1997, PDF) ont mené une expérience randomisée sur un projet réel : 88 inspections, taille d'équipe (1, 2 ou 4 relecteurs), nombre de séances et correction entre séances tirés au sort.
- Les traitements n'ont pas changé significativement l'efficacité de détection ; certaines combinaisons ont fortement allongé les délais.
- Deux ou quatre relecteurs : pas de différence ; un seul relecteur : moins efficace.
- Parmi les problèmes signalés : 22 % de faux positifs, 60 % de remarques de maintenabilité, 18 % seulement de vrais défauts.
Cette dernière répartition anticipe de quinze ans les résultats de la revue moderne.
L'efficacité de suppression des défauts selon Capers Jones¶
Capers Jones a popularisé l'efficacité de suppression des défauts (DRE) : la part des défauts éliminés avant livraison, rapportée aux défauts trouvés par les clients dans les 90 jours. Son article de 2011 (PDF) donne, à partir de « plus de 13 000 projets » :
| Méthode | DRE moyen (min-max) |
|---|---|
| Inspection formelle de conception | 87 % (65-97) |
| Inspection formelle de code | 85 % (60-96) |
| Analyse statique | 85 % (65-95) |
| Programmation en binôme | 55 % (40-65) |
| Revue informelle | 50 % (35-60) |
| Test unitaire | 38-40 % (15-50) |
| Test système | 42 % (27-55) |
| Moyenne des méthodes avant test | 69 % |
| Moyenne des méthodes de test | 44 % |
Selon Jones, la moyenne américaine était de 85 % de défauts éliminés en 2011, et dépasser 95 % est impossible par les tests seuls.
Limite importante : des chiffres invérifiables
Ces tableaux viennent de la base de données de conseil de Jones. Ils ne donnent ni taille d'échantillon par méthode, ni intervalle de confiance, et ne sont pas reproductibles. Jones lui-même compare la mesure du logiciel à « une fouille archéologique » et reconnaît que les données manquent pour conclure solidement (compte rendu d'Allan Kelly). À utiliser comme ordres de grandeur, pas comme mesures. Leur message qualitatif — les méthodes de lecture et d'analyse trouvent plus que les tests, et aucune méthode seule ne suffit — est cohérent avec Myers (1978) et Basili et Selby (1987), voir Tests.
Taille, vitesse et fatigue¶
L'étude SmartBear chez Cisco (2006)¶
L'étude la plus citée sur la taille des revues est celle publiée par Jason Cohen (SmartBear, éditeur de l'outil utilisé) dans Best Kept Secrets of Peer Code Review (chapitre Cisco) : 2 500 revues de 3,2 millions de lignes écrites par 50 développeurs sur 10 mois. Ses conclusions :
- moins de 200 lignes par revue, jamais plus de 400 : « au-delà, les relecteurs sont submergés » ;
- un rythme de moins de 300 lignes par heure donne la meilleure détection ; moins de 500 reste correct ;
- une revue de moins de 60 minutes, jamais plus de 90 : « les taux de détection s'effondrent ensuite ».
Les réserves sont importantes : étude d'un éditeur sur son propre outil, environ 21 % des revues écartées au nettoyage, défauts comptés à la main sur un échantillon de 300 revues, et un modèle du rythme d'inspection qui n'explique que 29 % de la variance (\(R^2 = 0{,}29\)). La promesse de « 70 à 90 % de défauts trouvés » qu'on lit sur le site de l'éditeur n'apparaît pas dans le chapitre.
La confirmation sur données PSP¶
Kemerer et Paulk (IEEE TSE 2009, PDF) ont analysé 617 programmes écrits pendant les formations PSP du SEI : le rythme de revue est un facteur significatif de l'efficacité, même en tenant compte de la compétence du développeur ; à 200 lignes par heure ou moins, la revue individuelle trouve près des deux tiers des défauts de conception et plus de la moitié des défauts de code. Réserve : ce sont des programmes de formation, pas des projets industriels.
Les études de la revue moderne¶
- Chez Microsoft, l'utilité des commentaires de revue baisse avec la taille de la modification, de façon visible à partir de 20 fichiers (Czerwonka et al., ICSE-SEIP 2015, PDF) ; Bosu, Greiler et Bird (MSR 2015) trouvent la même relation sur 1,5 million de commentaires.
- Une expérience contrôlée (Baum, Schneider, Bacchelli, EMSE 2019) trouve que l'efficacité de la revue est significativement plus grande pour les petites modifications (voir Facteurs humains).
Ce qui tient, malgré des sources imparfaites
Fagan (1976), l'étude Cisco (2006), Kemerer et Paulk (2009), Microsoft (2015) et Baum et al. (2019) mesurent la même chose avec des méthodes différentes et de qualité inégale : la détection baisse quand la revue est grosse, rapide ou longue. Les seuils exacts (200 ou 400 lignes, 60 ou 120 minutes) sont fragiles ; la direction est solide.
La revue moderne trouve peu de bugs¶
Ce qu'on attend et ce qu'on obtient¶
La revue « moderne » — légère, outillée, asynchrone, sur chaque modification — a remplacé l'inspection formelle. Bacchelli et Bird (ICSE 2013, PDF) ont interrogé 873 développeurs et 165 managers de Microsoft et classé 570 commentaires :
- trouver des défauts est la première motivation déclarée ;
- mais les commentaires sur des défauts ne représentent que 14 % du total (4e catégorie sur 9), et portent surtout sur de petites erreurs de logique ;
- les améliorations de code sont la première catégorie (29 %) ;
- la clé d'une revue est la compréhension du contexte et du changement.
Les études suivantes convergent :
| Étude | Part des remarques qui portent sur des défauts fonctionnels |
|---|---|
| Porter et al. (Lucent, 1997) | 18 % de vrais défauts parmi les problèmes signalés |
| Mäntylä et Lassenius (IEEE TSE 2009) | ~25 % (75 % des défauts trouvés ne touchent pas la fonctionnalité visible) |
| Bacchelli et Bird (Microsoft, 2013) | 14 % des commentaires |
| Czerwonka et al. (Microsoft, 2015) | ~15 % des commentaires |
Chez Google (Sadowski et al., ICSE-SEIP 2018, PDF, 9 millions de modifications), la revue est rapide (latence médiane de moins de 4 heures), porte sur de petites modifications (médiane de 24 lignes), a le plus souvent un seul relecteur, et sa raison d'être déclarée est la lisibilité et la maintenabilité, pas la recherche de bugs.
Mais la revue réduit quand même les défauts¶
Ne pas trouver de bugs dans les commentaires ne veut pas dire ne pas en empêcher :
- Bavota et Russo (ICSME 2015, PDF, 87 197 commits) : les commits non relus ont plus de deux fois plus de chances d'introduire un bug ;
- McIntosh et al. (MSR 2014, EMSE 2016) : sur Qt, VTK et ITK, une faible couverture de revue et une faible participation sont associées à jusqu'à 2 et 5 défauts supplémentaires après livraison par composant.
Mais la réplication de Krutauz, Dey, Rigby et Mockus sur Chrome (EMSE 2020, arXiv 2005.09217) trouve ces effets instables : des modèles sans variables de revue prédisent aussi bien les défauts, dominés par les défauts antérieurs, la taille et l'auteur. L'effet de la revue sur la qualité est probable, mais indirect et difficile à isoler.
La revue superficielle¶
- Kononenko et al. (Mozilla, ICSME 2015) : 54 % des modifications relues ont tout de même introduit des bugs ; la charge, l'expérience et la participation des relecteurs sont associées à la qualité de la revue ;
- Gön, Yetistiren et Tüzün (ICSME 2024) : 64,7 % des PR étudiées ont une revue sans aucun commentaire, et ces revues présentent 3,5 fois plus souvent une approbation de pure forme (LGTM) ;
- Thongtanunam et al. (MSR 2015, 11 736 revues de Qt) : les fichiers qui deviendront défectueux sont relus moins rigoureusement que les autres.
Ce que la revue humaine apporte vraiment
La recherche dessine un contrôle qui fait surtout trois choses : améliorer la maintenabilité (la majorité des remarques), diffuser la connaissance (Rigby et Bird mesurent que la revue augmente de 66 % à 150 % le nombre de fichiers qu'un développeur connaît), et dissuader les défauts plus qu'elle ne les trouve. Sa capacité de détection directe est modeste et chute avec la taille, la vitesse et la familiarité de façade.
La programmation en binôme¶
La méta-analyse de Hannay, Dybå, Arisholm et Sjøberg (Information and Software Technology 2009) trouve un petit effet positif du binôme sur la qualité, un effet moyen sur la durée, et un effet négatif moyen sur l'effort total, avec une forte variance entre études et des signes de biais de publication. L'effet dépend de la complexité : sur les tâches complexes, meilleure qualité au prix d'un effort nettement supérieur.
À retenir
- Les inspections formelles trouvent environ deux tiers des défauts avant test dans les meilleurs cas documentés ; le « 82 % » de Fagan est un cas isolé.
- La réunion d'inspection ajoute peu (environ 5 % chez Votta) ; un seul relecteur est moins efficace que deux.
- Les tableaux de Capers Jones (inspections ~85 %, tests ~40 %) sont des ordres de grandeur invérifiables, mais cohérents avec les expériences.
- La détection baisse avec la taille et la vitesse de la revue : la direction est solide, les seuils (200-400 lignes, 60-90 minutes) sont fragiles.
- La revue moderne produit surtout des remarques de maintenabilité (au moins la moitié des commentaires chez Microsoft ; 75 à 85 % des défauts trouvés selon Mäntylä et Lassenius) ; son effet sur les défauts est réel mais indirect, et une large part des revues est superficielle.