Debugging: Finding It Yourself

La plupart des débutants traitent un bug comme un mur. Ils le heurtent, s'arrêtent, et demandent à quelqu'un d'autre de l'escalader pour eux. L'habitude qui construit vraiment les compétences est différente : vous apprenez à traiter un bug comme une question qui a une réponse trouvable, et vous allez la chercher avant d'aller demander.

Lisez le message d'erreur comme s'il était une preuve, pas du bruit

Les stack traces sont constamment ignorées parce qu'elles ont l'air effrayantes. Mais elles vous disent généralement exactement où et pourquoi quelque chose s'est cassé. Si vous obtenez TypeError: 'NoneType' object is not subscriptable en Python, ce n'est pas du charabia aléatoire — ça signifie qu'une variable que vous vous attendiez à contenir une liste ou un dict est en fait None. Le numéro de ligne vous indique où. Votre travail est de remonter à partir de cette ligne et de trouver où la valeur aurait dû être définie mais ne l'a pas été.

Faites cela avant de chercher quoi que ce soit en ligne : lisez la dernière ligne du traceback en premier, puis remontez. La dernière ligne nomme généralement l'exception réelle. Les lignes au-dessus montrent la chaîne d'appels qui vous y a menés.

Reproduisez-le exprès

Si un bug n'apparaît que parfois, vous ne l'avez pas encore compris. Avant de toucher au code, essayez de le faire arriver de manière fiable. Changez une entrée à la fois. Est-ce qu'il échoue avec une liste vide mais pas avec une liste remplie ? Est-ce qu'il échoue seulement au deuxième appel d'une fonction, pas au premier ? Un bug que vous pouvez reproduire sur commande est un bug qui est à 80% résolu, parce que maintenant vous pouvez tester si un correctif a vraiment fonctionné au lieu de deviner.

Coupez le problème en deux, puis en deux à nouveau

La recherche binaire n'est pas juste pour les tableaux triés — c'est la façon la plus rapide de trouver du code cassé dans une longue fonction ou un pipeline. Commentez ou contournez la deuxième moitié de votre logique et vérifiez si la première moitié produit toujours le bug. Si oui, le problème est dans la première moitié. Si non, il est dans la deuxième. Recommencez. Cela fonctionne pour un script de 200 lignes tout aussi bien que pour un pipeline de données multi-étapes où vous vérifiez les sorties à chaque étape avec print() ou df.head().

Cela vaut mieux que de changer les lignes aléatoirement et de relancer, ce que la plupart des gens font sous la pression et qui gaspille beaucoup plus de temps qu'il ne sauve.

Utilisez le debugger au lieu de print() quand print() arrête de fonctionner

Les déclarations print() vont bien pour les cas simples, mais une fois que vous tracez l'état à travers plusieurs appels de fonction, un vrai debugger économise du temps réel. En Python, mettez import pdb; pdb.set_trace() juste avant la ligne suspecte, lancez le script, et vous obtenez une invite en direct où vous pouvez inspecter les variables, avancer ligne par ligne avec n, et entrer dans les appels de fonction avec s. Le debugger intégré de VS Code fait la même chose avec des points d'arrêt que vous cliquez au lieu de taper. Dans tous les cas, l'objectif est le même : regarder l'état réel de votre programme au lieu de deviner ce qu'il est probablement.

Isolez-le du reste de votre projet

Si un bug se produit dans une grande base de code, ne le debuggez pas dans la grande base de code. Copiez la fonction pertinente dans un nouveau fichier avec une entrée fausse et minimale qui déclenche le même échec. Si le bug disparaît, quelque chose à propos du contexte environnant — une variable globale, une importation, un état périmé — est la vraie cause, et vous venez d'apprendre quelque chose d'important. Si le bug persiste en isolation, vous avez maintenant un cas petit, partageble et testable, et vous êtes beaucoup plus proche du correctif réel.

Vérifiez vos hypothèses contre la réalité, pas la mémoire

Une énorme part du temps de debugging va à des hypothèses non questionnées :