Programmer
Déboguer avec méthode
Cinq étapes qui transforment la panique en diagnostic.
01Objectif
À la fin de cette séquence : Lire une trace d'erreur, isoler la cause, formuler une hypothèse vérifiable et corriger — au lieu de modifier au hasard jusqu'à ce que ça passe.
02L'essentiel
Lire l'erreur avant de toucher au code
La trace nomme le type d'erreur et la ligne. Elle se lit de bas en haut : la dernière ligne dit quoi, l'avant-dernière dit où.
Réduire jusqu'au plus petit cas qui échoue
Supprimez tout ce qui n'est pas nécessaire à reproduire le problème. Neuf fois sur dix, la cause devient évidente pendant cette réduction.
Une hypothèse à la fois
Changer trois choses puis relancer : en cas de succès, on ne sait pas laquelle. On formule une hypothèse, on la teste, on note le résultat.
Afficher les valeurs, ne pas les imaginer
Un print bien placé montre ce que contient vraiment la variable. La plupart des bugs viennent d'une valeur différente de celle qu'on supposait.
03Le schéma
04À retenir
- La trace d'erreur se lit de bas en haut.
- Reproduire d'abord. Un bug non reproductible n'est pas corrigeable.
- Une hypothèse, un test. Deux changements simultanés ne prouvent rien.
05Exercice
Prenez un programme qui fonctionne, introduisez volontairement trois erreurs — une faute de frappe, une confusion de type, une boucle infinie. Faites-le corriger par quelqu'un d'autre en lui demandant de dire à voix haute son hypothèse avant chaque essai.
Indice — L'exercice porte sur la verbalisation : c'est elle qui empêche les modifications au hasard.
06Vérification des acquis
Pourquoi lire une trace d'erreur de bas en haut ?
Parce que la dernière ligne indique la nature exacte de l'erreur, et celles au-dessus le chemin d'appels qui y a mené. On part du symptôme précis pour remonter à la cause.
Pourquoi ne changer qu'une chose à la fois ?
Parce que si le problème disparaît après trois modifications, vous ignorez laquelle a agi — et vous en avez peut-être introduit une nouvelle sans le voir.