Accueil / Vérifier ce qu'il rend

Où vous regardez détermine ce que vous trouvez

Une vérification pointée sur le dernier changement dit où l'on a regardé, jamais où sont réellement les défauts : sans avoir examiné le reste avec le même soin, aucune conclusion sur la dangerosité comparée du code récent et du code ancien ne tient.

Une vérification adverse relit presque toujours le dernier diff en premier, le dernier commit, le bloc qu'on vient de changer. Ce périmètre restreint est un choix raisonnable, mais il produit un effet trompeur si on l'oublie : ce que cette relecture trouve dépend d'abord de l'endroit où elle a cherché, pas seulement de l'endroit où les défauts se trouvent réellement.

Un compte sans dénominateur ne compare rien

Affirmer que le code récent est plus dangereux que le code ancien exigerait deux chiffres : la part du dépôt relue qui était récente, et le taux de défauts trouvé dans chacune des deux parts, ancienne et récente, à effort de relecture égal. Sans ces deux chiffres, un compte de défauts trouvés dans le dernier diff ne mesure que le périmètre choisi, jamais la dangerosité comparée des deux zones. C'est un biais de sélection ordinaire, reconnaissable dès qu'on le nomme : compter les seuls cas qui ont été remarqués, au lieu de la population entière, puis généraliser depuis ce sous-ensemble choisi, produit la même erreur, quel que soit le nom qu'on lui donne.

Le biais se vérifie sans dépendre d'aucun fichier vivant du cours, qui se réécrit à chaque correction et rendrait une sortie différente à chaque relecture. La commande qui suit fabrique elle même les deux fichiers qu'elle compte, avant de les compter : un lecteur qui la rejoue sur son propre poste obtient exactement la même sortie, aujourd'hui comme dans six mois. Compter combien de fois un mot apparaît dans un seul fichier, puis dans deux fichiers voisins, rend deux comptes corrects et deux comptes différents, sans qu'aucun des deux ne dise combien de fois ce mot apparaîtrait dans un ensemble plus large qui n'a pas été interrogé. La commande compte ici des occurrences, pas des lignes : grep -c compte des lignes contenant le motif, pas le nombre de fois qu'il y apparaît ; grep -o imprime chaque correspondance sur sa propre ligne, ce que wc -l peut ensuite compter sans confondre une ligne qui contient le mot une fois avec une ligne qui le contient trois fois.

$ printf 'Ce fichier decrit un défaut de comptage.\nUn deuxieme défaut apparait plus bas.\nUn troisieme défaut clot la liste.\n' > fichier-b.txt
$ grep -o "défaut" fichier-b.txt | wc -l
3
$ printf 'Ce fichier voisin decrit un premier défaut.\nPuis un second défaut.\n' > fichier-a.txt
$ grep -o "défaut" fichier-a.txt fichier-b.txt | wc -l
5

Le périmètre interrogé détermine le nombre trouvé. Trois, ou cinq, dépend uniquement du nombre de fichiers ouverts par la commande, pas d'une propriété plus profonde du texte fabriqué pour la démonstration.

Ce qui reste utile malgré le biais

Relire en priorité le dernier changement garde un sens, non parce qu'il concentrerait forcément plus de défauts, mais parce que c'est le seul code que personne d'autre n'a encore examiné. Une ligne ancienne a déjà survécu à plusieurs relectures et plusieurs exécutions. Une ligne écrite dix minutes plus tôt n'a survécu qu'à la relecture de son auteur, et cette relecture immédiate rejoue la même intention qui a produit l'erreur, si erreur il y a : elle ne peut pas la voir, comme le montre la leçon sur un vert qui n'a pas encore été mis en défaut. C'est un motif d'urgence, pas un motif statistique.

Une garde ou un contrôle tout juste ajouté pour corriger un défaut précis hérite de la même urgence : il vient de naître, personne ne l'a mis en défaut, et un vert qu'il rend aujourd'hui ne prouve rien de plus qu'un vert rendu par du code jamais éprouvé.