Accueil / Vérifier ce qu'il rend
Une vérification très rigoureuse peut quand même ne rien voir
Plus une méthode de contrôle est disciplinée, plus elle donne l'illusion d'avoir tout couvert, parce qu'elle ne peut juger que ce qui existe déjà, jamais ce qui manque entièrement.
Une vérification adverse, même très disciplinée, répond toujours à une question fermée : ce fragment de code fait-il ce qu'il prétend faire. Elle relit des fichiers, des fonctions, des écrans qui existent déjà dans le livrable qu'on lui soumet. Un écran jamais construit, une fonction jamais écrite, un parcours jamais branché n'apparaissent nulle part dans ce périmètre, donc aucune relecture, aussi minutieuse soit elle, ne peut les y trouver.
Un contrôle ne peut juger que ce qui existe
Ce n'est pas une faiblesse de méthode, c'est une limite structurelle du geste lui même : on ne relit que ce qui a été écrit. La preuve tient dans une seule commande, qui fabrique elle même le fichier qu'elle interroge avant de l'interroger, plutôt que de dépendre d'une correspondance vivante du projet susceptible d'être modifiée entre l'écriture de cette leçon et sa lecture :
$ printf 'v2m3l1\nv2m3l2\nv2m3l3\nv2m3l4\nv2m3l5\nv2m3l6\nv2m3l7\nv2m3l8\nv2m3l9\n' > planning.txt
$ grep -c "v2m3l10" planning.txt
0
$ echo "code de sortie : $?"
code de sortie : 1
La commande rend zéro occurrence sur sa sortie standard, parce qu'aucune chaîne ne correspond, et elle signale bien quelque chose par ailleurs : son code de sortie vaut 1, la convention par laquelle grep indique l'absence de correspondance. Le code de sortie fait partie de la sortie, au même titre que le texte affiché, et l'ignorer revient à perdre une partie de l'information déjà rendue. Ce signal ne dit pourtant pas qu'une leçon manque : que la dixième leçon du module ait été oubliée en cours de route ou qu'elle n'ait jamais été planifiée, la commande rendrait exactement le même zéro et le même code 1 dans les deux cas. Un contrôle confiné à ce que le fichier contient ne distingue pas ces deux situations.
La rigueur aggrave l'illusion au lieu de la corriger
Le résultat est contre intuitif : plus une méthode de contrôle est disciplinée sur ce qu'elle regarde, plus son verdict positif inspire confiance, et plus cette confiance devient trompeuse sur ce qu'elle n'a pas regardé du tout. Comme pour une relecture pointée sur le dernier diff, un vert obtenu par une méthode sérieuse se lit comme une couverture totale, alors qu'il ne dit rien de ce qui est absent du périmètre examiné.
Ce qui referme l'angle mort
Aucune discipline supplémentaire appliquée au même geste ne comble ce trou, puisque le geste porte par construction sur l'existant. Ce qui le comble est une question différente, posée en dehors du code relu : un parcours utilisateur complet plutôt qu'une liste de cas à vérifier, confié à un usage réel, même très bref, mené tôt par la personne concernée. Un tel usage n'est pas plus rigoureux qu'une relecture disciplinée, il examine un périmètre différent, celui qui inclut l'absence totale, là où une relecture de code ne peut par construction examiner que ce qui a été écrit.
Ce que la rigueur change, et ce qu'elle ne change jamais
Souvent raté
Un contrôle relâché laisse passer des défauts pourtant présents dans le code.
Raté aussi, sans surprise
Un contrôle relâché ne voit évidemment pas ce qui n'a jamais été écrit.
Ce que la rigueur change réellement
Un contrôle disciplinée relit ce qui existe avec le soin voulu, sans que cela dise combien de défauts échappent encore à ce même périmètre.
Raté quand même
Le même contrôle, aussi rigoureux soit il, ne peut rien dire d'un écran, d'une fonction ou d'un parcours jamais construits : ce n'est pas dans son périmètre.
Une correspondance de planification décrit un module de dix leçons, numérotées de un à dix, pour une équipe de rédaction. Plusieurs agents adverses reçoivent chacun les fichiers des neuf leçons déjà rédigées, avec pour instruction d'y chercher des défauts. Chaque agent remet un rapport de défauts limité aux fichiers qui lui ont été transmis.
Écrivez en une phrase ce que ce résultat établit, et en une phrase ce qu'il n'établit pas.
Ce que cela établit : Ces relectures jugent les fichiers de leçons qui leur ont été soumis, sans rien dire d'un fichier absent de ce qu'elles ont examiné.
Ce que cela n’établit pas : Le silence de ces relectures n'établit pas que l'absence de dixième leçon soit mineure ou sans conséquence, ni qu'un nouveau passage de relecture la repérera.
Les trois calibrages faux les plus courants
- Trop large Ce silence établit que la correspondance est complète et qu'aucune leçon ne manque à ce module.
- Trop étroit Ce silence n'établit rien du tout sur le travail fait par ces agents, puisqu'aucun défaut n'a été trouvé.
- À côté Ce silence montre que le nombre d'agents mobilisés était insuffisant pour ce travail.
- Une vérification adverse, aussi disciplinée soit elle, ne juge que ce qui existe déjà dans le périmètre qu'on lui soumet, jamais ce qui en est totalement absent.
- Un contrôle confiné à des fichiers existants rend le même silence face à un élément oublié et face à un élément qui n'a jamais été prévu : il ne distingue pas les deux cas.
- Plus une méthode de contrôle est rigoureuse sur son périmètre, plus son vert inspire une confiance qui déborde largement ce qu'elle a réellement couvert.
- Un usage réel bref n'est pas plus rigoureux qu'une relecture disciplinée : il examine un périmètre différent, celui qui inclut l'absence totale.
Ouvrez un produit ou un livrable que vous venez de faire relire avec soin, et tentez d'atteindre son but final sans suivre aucune instruction ni documentation. Notez chaque point où vous vous arrêtez sans savoir quoi faire. Le nombre de points d'arrêt est votre résultat vérifiable, et chacun est un candidat à un élément que la relecture de code n'a jamais pu voir.