Unité 5 / 12

Débogage et dépannage

Gains :

  • Capacité à décrire efficacement un bug à l'IA avec un message d'erreur, une trace de pile et la plus petite instance de reproduction
  • Capacité à exécuter un flux de débogage systématique avec l'IA pour trouver la cause première en émettant des hypothèses et en la réduisant étape par étape
  • Possibilité de vérifier que le correctif suggéré par l'IA a réellement résolu le problème en reproduisant et en effectuant des tests de régression

Le débogage consiste à découvrir pourquoi un programme se comporte différemment que prévu et à le corriger, et cela prend beaucoup de temps pour la plupart des ingénieurs. Un bon débogage ne repose pas sur un jeu de devinettes, mais sur un affinement systématique : clarifier le symptôme, émettre une hypothèse, tester l’hypothèse, trouver la cause profonde. L’IA est un partenaire très puissant dans ce cycle ; Mais seulement si vous lui donnez les bonnes informations. Dire « le code ne fonctionne pas, corrigez-le » oblige l'IA à deviner et à faire des suggestions générales. Donnez-lui le message d'erreur complet, la trace de la pile et le plus petit échantillon de reproduction, et ensemble vous trouverez la cause première.

Dans cette unité, nous verrons comment décrire efficacement un bug à l'IA, affiner les hypothèses étape par étape et vérifier par des tests de régression que le correctif proposé résout réellement le problème. N'oubliez pas : « corriger » un bug et « supprimer le symptôme du bug » sont deux choses différentes ; Une correction effectuée sans trouver la cause première déplace l'erreur vers un autre endroit.

Concepts : Trace de pile : Un dump montrant quelles fonctions ont été appelées dans quel ordre au moment de l'erreur. Reproduction minimale : le code/l'entrée le plus simple et le plus court qui déclenche l'erreur. Cause fondamentale : la véritable source du problème, pas le symptôme. Tests de régression : tests garantissant que la même erreur ne se répète pas.

Décrire un bug à l'IA

La probabilité que l’IA trouve la cause profonde est directement proportionnelle à la qualité des informations que vous fournissez. Une bonne description de l'erreur comprend : ce que vous avez essayé de faire, ce à quoi vous vous attendiez, ce qui s'est passé, le texte exact de l'erreur et la trace de la pile, le code impliqué, l'environnement (langue/version/OS) et le plus petit échantillon qui a produit l'erreur.

  1. Clarifiez le symptôme. Au format "X attendu, Y actualisé".
  2. Collez le texte d'erreur complet et la trace de la pile. Ne le raccourcissez pas, ne le censurez pas, mais ne brisez pas la structure.
  3. Donnez la plus petite reproduction. Entrée minimale et code qui déclenche l'erreur.
  4. Spécifiez l'environnement. Version linguistique, version bibliothèque, environnement d'exécution.

Invite de description d'erreur efficace : "Je débogue un bug. Informations : - Ce que j'essaie de faire : [X] - Comportement attendu : [Y] - Comportement réel : [Z] - Message d'erreur complet et trace de pile : [coller] - Environnement : [langue/version, bibliothèque/version] - Code minimum impliqué : [code] Ne me donnez pas de solution directe. Énumérez d'abord les 3 causes profondes les plus probables par ordre de probabilité et dites-moi quelle vérification vérifier pour chacune. "

Rétrécissement du flux par hypothèse

Le débogage systématique est l’art d’éliminer les possibilités une par une. Utiliser l'IA pour générer des hypothèses et concevoir l'expérience pour tester chaque hypothèse ; Exécutez ensuite l’expérience et renvoyez le résultat. Ce cycle est beaucoup plus rapide que l'habitude d'effectuer des modifications aléatoires et de s'arrêter, appelée « débogage du fusil de chasse ».

Invite d'aide à la recherche binaire (bissection) : « Cette erreur n'était pas là hier, elle est là aujourd'hui. Je veux savoir laquelle des 20 dernières modifications a provoqué l'erreur avec la bissection. Donnez-moi un plan étape par étape : quel point dois-je tester, à quelle moitié dois-je aller en fonction du résultat. Dites-moi également exactement ce qu'il faut vérifier à chaque étape.

Invite de stratégie d'insertion de journal : "Je ne trouve pas l'erreur car je ne vois pas les valeurs intermédiaires dans cette fonction. Dites-moi à quels moments je dois ajouter des lignes de journal qui impriment quelles variables. Ajoutez une explication "que vais-je apprendre de ce journal" pour chaque journal. Spécifiez également les avertissements qui m'empêcheront de consigner des données confidentielles. "

Astuce : Si vous ne parvenez pas à résoudre une erreur, la plupart du temps, le problème vient d'un endroit que vous avez mal supposé. Demandez à l’IA « quelle de mes hypothèses pourrait être fausse ? » Demander brisera votre cécité. Les erreurs les plus graves se cachent là où vous dites « Je suis sûr que cela fonctionne bien ».

Invite faible/Invite forte

FAIBLE : "Mon code donne une erreur, corrigez-la : [200 lignes de code]" (Résultat : l'IA ne sait pas de quelle erreur il s'agit, ce qui est attendu ; elle donne des suggestions générales basées sur des suppositions, la plupart d'entre elles sont inutiles.) FORT : "J'obtiens NullPointerException. Attendu : la liste des utilisateurs doit être renvoyée. Réel : explose lors de l'appel à getUsers(). Trace de pile : [coller]. Environnement : Java 17. Répétition minimale : cela se produit lorsque la liste des utilisateurs est vide, mais pas lorsqu'elle est pleine. 15 lignes associées : [code] Expliquez la cause première et pourquoi la liste vide est déclenchée, puis suggérez un correctif. "

L'invite puissante place l'erreur dans son contexte : auquel cas elle se produit (liste vide), auquel cas elle ne se produit pas (liste complète). Ce seul indice (« se produit lorsqu’il est vide ») pointe presque directement vers la cause profonde. Puisque cette information n’est pas disponible dans l’invite faible, l’IA fait une supposition aveugle.

Vérification du correctif

Un correctif n'est un véritable correctif que s'il fait trois choses :

contrôle

Question

Comment vérifier

L'erreur a disparu ?

La même entrée fonctionne-t-elle maintenant ?

Exécutez à nouveau la reproduction minimale

Pas de nouvelles erreurs ?

Y a-t-il autre chose de cassé ?

Exécutez l’intégralité de la suite de tests

Cela ne va-t-il pas se répéter ?

La même erreur se reproduira-t-elle ?

Ajouter un test de régression pour ce scénario

Les corrections apportées sans trouver la cause profonde suppriment souvent le symptôme. Par exemple, passer sous silence une erreur nulle avec "skip if null" donne la vraie raison, "pourquoi les données arrivent-elles nulles ?" invisible, et l’erreur se reproduit ailleurs.

Mini-étuis

Cas 1 — Le piège de la suppression des symptômes. Une équipe fait taire une erreur nulle occasionnelle avec un try-catch ; L'erreur disparaît mais après 2 semaines les données semblent manquantes. La vraie raison est qu'un service renvoie null à l'expiration du délai. Lorsque vous demandez à l’IA « pourquoi devient-elle nulle ? », la cause profonde apparaît ; Le vrai correctif prend 1 heure mais est permanent.

Cas 2 — Puissance de reproduction minimale. Un développeur ne peut pas corriger un bug qui dit "il plante de temps en temps". Il réduit l'erreur à la plus petite entrée avec la suggestion d'AI : le problème ne se produit qu'avec les noms de fichiers contenant des caractères turcs (erreur d'encodage). Lorsque 300 lignes d'incertitude sont réduites à 5 lignes de reproduction définitive, la solution devient évidente.

Cas 3 — Test anti-régression. L'IA corrige une erreur de calcul de date. L'ingénieur n'est pas satisfait de cela ; ajoute un test de régression pour le scénario erroné (fin de mois, 31 janvier + 1 mois). Lorsqu'un autre changement touche la même zone 4 mois plus tard, le test devient rouge et le bug est détecté avant d'atteindre la production.

Erreurs courantes

  • Cela signifie "ça ne marche pas, répare-le". Sans texte d'erreur, attente et repro, l'IA devine.
  • Ne pas donner la trace de la pile. La trace de pile indique souvent directement la cause première.
  • Continuez à apporter des modifications aléatoires. Les expériences sans établir d’hypothèse font perdre du temps.
  • Supprimer le symptôme et passer à côté de la cause profonde. L'erreur renaît ailleurs.
  • Ne pas sécuriser le correctif avec des tests de régression. La même erreur revient silencieusement dans le futur.

En résumé

Un débogage efficace consiste à rétrécir systématiquement, et non à deviner. Donner à l'IA le texte complet de l'erreur, la trace de la pile, la reproduction minimale et les informations sur l'environnement augmente de manière exponentielle les chances de trouver la cause première. Utiliser l'IA pour générer des hypothèses et concevoir l'expérience pour tester chaque hypothèse ; Vous effectuez l'expérience. Considérez un correctif comme « terminé » uniquement lorsque vous voyez que le bogue a disparu, qu'aucun nouveau bogue n'est introduit et qu'il est protégé par des tests de régression.

Tâche de candidature

Considérez une erreur réelle ou artificielle. Réduisez d’abord l’erreur à la plus petite reproduction (dans quelle entrée elle se produit, dans laquelle elle ne se produit pas). À l'aide de l'invite de recette de bogue efficace, demandez à l'IA 3 hypothèses de cause première et une étape de vérification pour chacune. Trouvez la cause première en testant les hypothèses une par une, corrigez-la, puis écrivez et exécutez un test de régression pour ce scénario afin de montrer que le bogue a disparu et que le test offre une protection.

liste de contrôle

  • [ ] J'ai clarifié le symptôme comme étant « attendu ou réalisé ».
  • [ ] J'ai donné le texte complet de l'erreur et la trace de la pile à l'IA.
  • [ ] J'ai réduit l'erreur à la plus petite reproduction.
  • [ ] En testant les hypothèses une par une, j'ai trouvé la cause profonde.
  • [ ] Au lieu de supprimer le symptôme, j’ai corrigé la cause profonde.
  • [ ] J'ai ajouté et exécuté un test de régression pour la même erreur.