Comment déboguer le code le plus efficacement possible? [fermé]

Les bogues qui se glissent dans le code peuvent être minimisés, mais pas entièrement éliminés car ils sont écrits - les programmeurs sont, bien que beaucoup soient en désaccord , uniquement des humains.

Lorsque nous détectons une erreur dans notre code, que pouvons-nous faire pour la supprimer? Comment devrions-nous l'aborder pour tirer le meilleur parti de notre temps précieux et nous permettre de passer moins de temps à essayer de le trouver et de coder plus de temps? Aussi, que devrions-nous éviter lors du débogage?

Notez ici que nous ne parlons pas de la prévention des bugs; nous parlons ce qu'il faut faire quand les bugs n'apparaissent. Je sais qu’il s’agit d’un vaste domaine susceptible de dépendre fortement du langage, de la plate-forme et des outils. Si c'est le cas, continuez à inclure des réponses telles que des mentalités et des méthodes générales.

L’état d’esprit et l’attitude vis-à-vis du débogage constituent peut-être la partie la plus importante, car ils déterminent l’efficacité avec laquelle vous corrigez l’erreur et ce que vous en tirerez, le cas échéant.

Les classiques du développement logiciel tels que The Pragmatic Programmer et Code Complete plaident fondamentalement pour la même approche: chaque erreur est une occasion d'apprendre, presque toujours sur vous-même (car seuls les débutants blâment le compilateur / ordinateur en premier).

Alors traitez-le comme un mystère qu'il sera intéressant de percer. Et résoudre ce mystère doit être fait systématiquement, en exprimant nos hypothèses (à nous-mêmes ou aux autres), puis en testant nos hypothèses, un par un si besoin est - en utilisant tous les outils à notre disposition, en particulier les débogueurs et les frameworks de tests automatisés. Ensuite, une fois le mystère résolu, vous pouvez faire encore mieux en parcourant tout votre code pour rechercher les erreurs similaires que vous avez pu commettre. et écrivez un test automatisé pour vous assurer que l'erreur ne se reproduira plus sans le savoir.

Une dernière remarque - je préfère appeler les erreurs "erreurs" et non pas "insectes" - Dijkstra a reproché à ses collègues d'utiliser ce dernier terme, car il est malhonnête. Ne cherchez pas, au lieu d’être là à cause de notre propre pensée (bâclée): http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

Nous pourrions, par exemple, commencer par nettoyer notre langue en n'appelant plus de bogue un bogue mais en l'appelant une erreur. C’est beaucoup plus honnête, parce que c’est à blâmer, comme il se doit. avec le programmeur qui a commis l'erreur. La métaphore animiste du bogue qui se glissait malicieusement pendant que le programmeur ne cherchait pas à le regarder était intellectuellement malhonnête, car elle dissimulait que l'erreur était sa propre création. L’avantage de ce simple changement de vocabulaire est qu’il a un effet aussi profond: alors qu’avant, un programme avec un seul bogue était "presque correct", un programme avec une erreur était ensuite "mauvais" (car Erreur).

1. Écrire des tests. Les tests permettent non seulement de prévenir les bogues (d'après mon expérience, TDD élimine presque tous les bogues insignifiants et stupides), mais contribue également beaucoup au débogage. Les tests forcent votre conception à être plutôt modulaire, ce qui facilite beaucoup l'isolement et la réplication du problème. En outre, vous contrôlez l'environnement, il y aura donc beaucoup moins de surprises. De plus, une fois que vous avez un cas de test manquant, vous pouvez être raisonnablement sûr que vous avez compris la vraie raison du comportement qui vous dérange.

2. Apprenez à utiliser un débogueur. printles déclarations peuvent fonctionner raisonnablement bien à un certain niveau, mais un débogueur est la plupart du temps très utile (et une fois que vous savez l’utiliser, il est beaucoup plus confortable que les printdéclarations).

3. Parlez de votre problème à quelqu'un, même s'il ne s'agit que d'un canard en caoutchouc . Le fait de vous forcer à exprimer le problème sur lequel vous travaillez en utilisant des mots fait vraiment des miracles.

4. Donnez-vous une limite de temps. Si, par exemple, vous sentez que vous n'allez nulle part après 45 minutes, il vous suffit de passer à d'autres tâches pendant un certain temps. Lorsque vous reviendrez à votre bogue, vous pourrez espérer voir d’autres solutions possibles que vous n’auriez pas envisagées auparavant.

Je pense que la reproduction d'un bug est également importante. Tous les cas qui reproduisent le bogue peuvent être répertoriés et vous pouvez ensuite vous assurer que votre correctif de bogue couvre tous ces cas.

Pourquoi les programmes échouent , un excellent livre que j'ai lu à ce sujet , qui présente diverses stratégies pour détecter les bogues, allant de l’application de la méthode scientifique pour isoler et résoudre un bogue au débogage delta. L'autre partie intéressante de ce livre est qu'il supprime le terme "bug". L'approche de Zeller est la suivante:

(1) Un programmeur crée un défaut dans le code. (2) Le défaut provoque une infection (3) L'infection se propage (4) L'infection provoque une défaillance.

Si vous souhaitez améliorer vos compétences en matière de débogage, je recommande vivement ce livre.

D'après mon expérience personnelle, nous avons trouvé beaucoup de bugs dans notre application, mais la direction nous presse simplement pour obtenir de nouvelles fonctionnalités. J'ai souvent entendu "Nous avons trouvé ce bug nous-mêmes et le client ne l'a pas encore remarqué, alors laissez-le jusqu'à ce qu'ils le fassent". Je pense qu'être réactif, opposé à proactif dans la correction des bugs, est une très mauvaise idée, car lorsque le moment est venu de résoudre le problème, vous avez d'autres problèmes à résoudre et une gestion plus riche en fonctionnalités que vous souhaitez gérer dès que possible. dans un cercle vicieux qui peut engendrer beaucoup de stress et d’épuisement professionnel et, en fin de compte, un système défectueux.

La communication est également un autre facteur lorsque des bugs sont trouvés. Envoyer un courrier électronique ou le documenter dans l'outil de suivi des bogues, ça va, mais, dans ma propre expérience, d'autres développeurs trouvent un bogue similaire et préfèrent ne pas réutiliser la solution que vous avez proposée pour corriger le code (car ils ont tout oublié. ), ils ajoutent leurs propres versions, de sorte que vous avez 5 solutions différentes dans votre code et que cela a l'air plus gonflé et déroutant. Par conséquent, lorsque vous corrigez un bogue, assurez-vous que quelques personnes l'examinent et vous transmettent des commentaires au cas où elles auraient corrigé un problème similaire et ont trouvé une bonne stratégie pour le résoudre.

Limist a mentionné le livre The Pragmatic Programmer, qui contient des informations intéressantes sur la correction des bogues. En utilisant l'exemple que j'ai donné dans le paragraphe précédent, je regarderais ceci: Software Entrophy , où l'analogie avec une veuve brisée est utilisée. Si deux fenêtres brisées apparaissent, votre équipe peut devenir apathique à le réparer, à moins que vous ne preniez une position proactive.

Bug, erreur, problème, défaut - peu importe comment vous l'appelez, cela ne fait pas beaucoup de différence. Je vais m'en tenir au problème puisque c'est ce à quoi je suis habitué.

1. Déterminez quelle est la perception du problème: traduisez le mot "Bob n'est toujours pas dans le système" en "Lorsque j'essaie de créer un enregistrement d'utilisateur pour Bob, il échoue avec une exception de clé dupliquée, bien que Bob ne l'ait pas déjà. à l'intérieur
2. Déterminez s'il s'agit vraiment d'un problème ou simplement d'un malentendu (en effet, Bob n'y est pas, personne ne s'appelle Bob, et l'insertion devrait fonctionner).
3. Essayez de suivre un nombre minimal d'étapes fiables pour reproduire le problème - par exemple, 'Dans le cas d'un système avec un enregistrement d'utilisateur' Bruce ', lorsqu'un enregistrement d'utilisateur' Bob 'est inséré, une exception se produit'
4. Ceci est votre test - si possible, placez-le dans un harnais de test automatisé que vous pouvez exécuter encore et encore, ce sera inestimable lors du débogage. Vous pouvez également en faire une partie de votre suite de tests pour vous assurer que ce problème particulier ne réapparaîtra pas plus tard.
5. Sortez votre débogueur et commencez à mettre des points d'arrêt - déterminez le chemin du code lorsque vous exécutez votre test et déterminez ce qui ne va pas. Ce faisant, vous pouvez également affiner votre test en le rendant aussi étroit que possible - idéalement en un test unitaire.
6. Corrigez-le - vérifiez que votre test réussit.
7. Vérifiez que le problème d'origine décrit par le client est également corrigé (très important - vous avez peut-être simplement corrigé un sous-ensemble du problème). Vérifiez que vous n'avez pas introduit de régressions dans d'autres aspects du programme.

Si vous connaissez très bien le code, ou si le problème ou la solution est évident, vous pouvez ignorer certaines de ces étapes.

Comment devrions-nous l'aborder pour tirer le meilleur parti de notre temps précieux et nous permettre de passer moins de temps à essayer de le trouver et de coder plus de temps?

Je suis en désaccord avec cela, car cela implique que l’écriture de nouveau code est plus utile que d’avoir un programme de travail de haute qualité. Il n’ya rien de mal à être aussi efficace que possible à la résolution des problèmes, mais un programme ne s’améliore pas nécessairement en y ajoutant simplement du code.

J'aime la plupart des autres réponses, mais voici quelques conseils sur ce qu'il faut faire AVANT de le faire. Vous permettra de gagner beaucoup de temps.

1. Déterminez s'il y a vraiment un bug. Un bug est TOUJOURS une différence entre le comportement du système et les exigences; le testeur doit pouvoir exprimer le comportement attendu et réel. S'il est incapable de fournir une assistance pour le comportement attendu, il n'y a pas d'exigence et il n'y a pas de bogue - juste l'opinion de quelqu'un. Renvoie le.

2. Considérez la possibilité que le comportement attendu est faux. Cela pourrait être dû à une mauvaise interprétation de l'exigence. Cela pourrait également être dû à un défaut dans l'exigence elle-même (un delta entre une exigence détaillée et une exigence métier). Vous pouvez aussi les renvoyer.

3. Isolez le problème. Seule l'expérience vous apprendra le moyen le plus rapide de le faire - certaines personnes peuvent presque le faire avec leur instinct. Une approche de base consiste à modifier une chose tout en maintenant toutes les autres choses constantes (le problème se pose-t-il sur d'autres environnements? Avec d'autres navigateurs? Dans une région de test différente? À différents moments de la journée?). Une autre approche consiste à examiner les décharges de pile ou messages d'erreur - parfois, vous pouvez simplement dire par la manière dont il est formaté quel composant du système a généré l'erreur d'origine (par exemple, si c'est en allemand, vous pouvez en vouloir à ce tiers avec lequel vous travaillez à Berlin).

4. Si vous vous êtes limité à deux systèmes qui collaborent, inspectez les messages entre les deux systèmes via le moniteur de trafic ou les fichiers journaux, puis déterminez quel système se comporte comme prévu et quel système ne le fait pas. S'il y a plus de deux systèmes dans le scénario, vous pouvez effectuer des vérifications par paire et contourner la pile d'applications.

5. La raison pour laquelle l’isolement du problème est si critique est qu’il n’est peut-être pas dû à un défaut de code sur lequel vous avez le contrôle (par exemple, des systèmes tiers ou l’environnement) et que vous souhaitez amener cette partie à prendre le relais le plus rapidement possible. . C’est à la fois une sauvegarde de votre travail et une mise au point immédiate afin que la résolution puisse être atteinte dans les meilleurs délais. Vous ne voulez pas travailler sur un problème pendant dix jours seulement pour découvrir que c'est vraiment un problème avec le service Web de quelqu'un d'autre.

6. Si vous avez déterminé qu'il y a vraiment un défaut et que c'est le code que vous contrôlez, vous pouvez isoler davantage le problème en recherchant la dernière construction "connue" et en inspectant les journaux de contrôle de source pour connaître les modifications pouvant avoir causé le problème. Cela peut économiser beaucoup de temps.

7. Si vous ne parvenez pas à le comprendre à partir du contrôle de code source, le moment est venu d'associer votre débogueur et de parcourir le code pour le comprendre. De toute façon, vous avez probablement une bonne idée du problème.

Une fois que vous savez où se trouve le bogue et que vous pouvez penser à un correctif, voici une bonne procédure pour le corriger:

1. Ecrivez un test unitaire qui reproduit le problème et échoue.

2. Sans modifier le test unitaire, faites le passer (en modifiant le code de l'application).

3. Conservez le test unitaire dans votre suite de tests pour éviter / détecter la régression.

Voici comment je le fais:

1. utilisez la même méthode à chaque fois pour trouver le problème. Cela améliorera votre temps de réaction aux erreurs.
2. Le meilleur moyen est probablement de lire le code. C'est parce que toutes les informations sont disponibles dans le code. Vous avez juste besoin de moyens efficaces pour trouver la position correcte et la capacité de comprendre tous les détails.
3. le débogage est une méthode très lente, et nécessaire uniquement si vos programmeurs ne comprennent pas encore comment l'ordinateur exécute les instructions asm / ne comprend pas les piles d'appels et les éléments de base
4. Essayez de développer des techniques de preuve comme l’utilisation de prototypes de fonctions pour raisonner sur le comportement du programme. Cela aidera à trouver la bonne position plus rapidement

Lorsque nous détectons une erreur dans notre code, que pouvons-nous faire pour la supprimer? Comment devrions-nous l'aborder pour tirer le meilleur parti de notre temps précieux et nous permettre de passer moins de temps à essayer de le trouver et de coder plus de temps? Aussi, que devrions-nous éviter lors du débogage?

En supposant que vous soyez dans un environnement de production, voici ce que vous devez faire:

1. Décrivez correctement "l'erreur" et identifiez les événements qui en sont à l'origine.

2. Déterminez si "l'erreur" est une erreur de code ou une erreur de spécification. Par exemple, la saisie d'un nom d'une lettre peut être considérée comme une erreur pour certains systèmes, mais un comportement acceptable pour d'autres systèmes. Parfois, un utilisateur signalait une erreur qu'il pensait être un problème mais ses attentes concernant le comportement du système ne faisaient pas partie des exigences.

3. Si vous avez prouvé qu'il y avait une erreur et que l'erreur est due au code, vous pouvez alors déterminer quels morceaux de code doivent être corrigés pour éviter l'erreur. Examinez également l’effet du comportement sur les données actuelles et les opérations futures du système (analyse d’impact sur le code et les données).

4. À ce stade, vous auriez probablement une estimation de la quantité de ressources qui sera utilisée pour résoudre le bogue. Vous pouvez le corriger tout de suite ou programmer un correctif dans une prochaine version du logiciel. Cela dépend également de la volonté de l'utilisateur final de payer pour le correctif. Vous devez également évaluer différentes options disponibles pour corriger l'erreur. Il peut y avoir plus d'un moyen. Vous devez sélectionner l'approche qui convient le mieux à la situation.

5. Analysez les raisons qui ont provoqué l'apparition de ce bogue (exigences, codage, test, etc.). Appliquer des processus qui empêcheraient la condition de se reproduire.

6. Documentez l'épisode de manière adéquate.

7. Libérez le correctif (ou la nouvelle version)