Faire corriger un défaut dont la cause est établie

Quand l’employer

À employer une fois la cause désignée et le test de non régression écrit. À ne pas employer tant que le test qui échoue n'existe pas : vous n'auriez aucun moyen de savoir si la correction agit.

Les 4 trous à remplir avant d’envoyer

Chaque trou est une décision déjà prise. Un trou que vous ne savez pas remplir n’est pas une case à improviser : c’est un travail de cadrage qui manque.

{CAUSE_ETABLIE}

Quelle cause a été établie, à quel fichier et quelle ligne ?

Pourquoi ce trou existe. Une correction lancée sans cause désignée devient une exploration, et l'exploration modifie beaucoup pour trouver un peu.

Si vous ne savez pas répondre. Revenez au gabarit d'enquête. Corriger sans cause est la première source de défauts introduits pendant une correction.

{TEST_QUI_ECHOUE}

Quel test échoue aujourd'hui et devra passer après la correction ?

Pourquoi ce trou existe. Le passage du test est la seule preuve de correction qui ne repose pas sur la parole de l'agent.

Si vous ne savez pas répondre. Faites écrire le test d'abord, avec un agent distinct. Sans lui, vous validerez une correction sur une affirmation.

{PERIMETRE_AUTORISE}

Quels fichiers la correction a-t-elle le droit de toucher ?

Pourquoi ce trou existe. Une correction dont le périmètre n'est pas gelé s'étend au refactoring, et l'on ne sait plus lequel des changements a corrigé quoi.

Si vous ne savez pas répondre. Limitez au fichier désigné par l'enquête. Si l'agent affirme que c'est insuffisant, faites-lui expliquer pourquoi avant d'élargir.

{RISQUE_ACCEPTE}

Quel effet de bord acceptez-vous, et lequel refusez-vous absolument ?

Pourquoi ce trou existe. Toute correction a un effet ailleurs. Décider à l'avance ce qui est tolérable évite de découvrir l'arbitrage une fois qu'il est fait.

Si vous ne savez pas répondre. Refusez au minimum toute perte de donnée et tout changement visible par l'utilisateur qui n'a pas été demandé.

Le corps du gabarit

Quatre parties, toujours dans cet ordre : le rôle et le mandat, le contexte factuel, la demande bornée, le format de sortie exigé. Les trous restent visibles à la copie, et c’est voulu : les remplir un par un est la dernière occasion de s’apercevoir qu’une décision manque.

## 1. RÔLE ET MANDAT

Tu es développeur, et tu appliques une correction sur une cause déjà établie par une enquête. Ton mandat est de faire passer un test qui échoue, en touchant le moins de code possible. Tu n'améliores rien au passage.

## 2. CONTEXTE FACTUEL

Cause établie : {CAUSE_ETABLIE}
Test qui échoue aujourd'hui : {TEST_QUI_ECHOUE}
Fichiers que tu peux toucher : {PERIMETRE_AUTORISE}
Effets de bord acceptés et refusés : {RISQUE_ACCEPTE}

La cause ne se rediscute pas ici. Si tu es convaincu qu'elle est fausse, tu t'arrêtes et tu le dis, tu ne corriges pas ailleurs de ta propre initiative.

## 3. DEMANDE BORNÉE

Applique la correction.

Ce que je veux :
1. le plus petit changement qui fait passer le test qui échoue ;
2. la liste des fichiers touchés, tous dans le périmètre autorisé ;
3. le résultat de l'exécution des tests, avant et après, recopié ;
4. ce que la correction change pour l'utilisateur, y compris quand la réponse est « rien » ;
5. les cas déjà en base qui portent la trace du défaut, et ce qu'il advient d'eux ;
6. ce que tu as vu et laissé en l'état pendant la correction.

Ce que je ne veux pas : un refactoring, une amélioration de lisibilité, une correction d'un second défaut, une mise à jour de dépendance, un changement de comportement non demandé.

## 4. FORMAT DE SORTIE EXIGÉ

Le résultat des tests est recopié tel quel, avant et après. La liste des fichiers touchés précède le code. La question des données déjà abîmées reçoit une réponse, même quand cette réponse est qu'il n'y en a pas.

Ta réponse est refusable si le périmètre a été dépassé, si le résultat des tests n'est pas recopié, ou si un second défaut a été corrigé au passage.

Ce que vous devez recevoir

• Le plus petit changement faisant passer le test qui échouait.
• Le résultat des tests recopié tel quel, avant et après la correction.
• La liste des fichiers touchés, tous dans le périmètre autorisé.
• L'effet de la correction pour l'utilisateur, même quand il est nul.
• Le sort des données déjà abîmées par le défaut.
• Une liste de ce qui a été vu et laissé en l'état.

Ce qui doit vous faire refuser

Ces motifs sont écrits comme des constats : « un fichier hors périmètre a été modifié » se vérifie, « le travail manque de rigueur » ne se vérifie pas.

• Un fichier hors périmètre a été touché pour rendre la correction plus propre.
• Le résultat des tests est affirmé au lieu d'être recopié.
• Un second défaut a été corrigé dans le même envoi, rendant la revue impossible.
• Les données déjà abîmées par le défaut sont ignorées sans décision écrite.
• La correction change un comportement visible sans que ce changement ait été demandé.
• Le test qui échouait a été modifié pour qu'il passe, au lieu de corriger le code.

Selon pour qui vous construisez

Pour un client.

La correction livrée au client est accompagnée du test qui la garde et de la date. Une correction sans test se reproche à la prochaine occurrence.