Diagnostiquer les bugs
Construire un signal pass/fail rapide et spécifique avant de former une théorie solide. Masquer les secrets dans les commandes, la sortie, les traces et les artefacts sauvegardés.
Boucle
- Reproduire. Écrire une commande qui atteint le symptôme exact de l'utilisateur et peut échouer sur ce bug. S'il n'existe pas de reproducer serré, lire references/feedback-loop.md.
- Minimiser. Supprimer les entrées, les étapes, les appelants et la configuration un par un. Ne conserver que ce dont l'échec a besoin.
- Hypothèse. Écrire 3 à 5 causes falsifiables classées par ordre de probabilité. Pour chacune, nommer l'observation qui la confirmerait ou l'infirmerait.
- Sonder. Modifier une variable à la fois. Privilégier un débogueur ou une instrumentation ciblée aux limites. Marquer les logs temporaires avec un préfixe unique
[DEBUG-...]. - Verrouiller la correction. Transformer la plus petite reproduction réelle en un test de régression qui échoue, au bon point d'interface public. Appliquer la plus petite correction. Relancer le test et la reproduction originale.
- Nettoyer. Supprimer l'instrumentation temporaire et les harnais. Signaler la cause, les preuves, la correction et toute lacune de couverture restante.
Règles
- Après deux tentatives de correction échouées, s'arrêter. Revérifier l'hypothèse ou la conception avant d'essayer un autre correctif. Ne pas empiler les suppositions.
- Pour une régression de performance, mesurer une base de référence et profiler ou bissecter avant de modifier le code. Les logs seuls ne constituent pas un diagnostic de performance.
- S'il n'existe pas de correct test seam, le dire. Après la correction, utiliser
$codebase-designpour juger si l'absence de point d'interface nécessite un travail structurel. - Ne revendiquer le succès que lorsque le symptôme original a disparu et que le test de régression est passé.