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

Létat desprit et lattitude envers le débogage sont peut-être la partie la plus importante, car elle détermine avec quelle efficacité vous corrigerez lerreur et ce que vous en apprendrez – le cas échéant.

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

Traitez donc ça comme un mystère quil sera intéressant de percer. Et percer 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, une par une si besoin est – en utilisant tous les outils à notre disposition, en particulier les débogueurs et les cadres de test automatisés. Ensuite, une fois le mystère résolu, vous pouvez faire encore mieux en recherchant dans tout votre code des erreurs similaires que vous avez pu commettre; et rédigez un test automatisé pour vous assurer que lerreur ne se reproduira plus sans le savoir.

Une dernière remarque – je préfère appeler les erreurs « erreurs » et non « bogues » – Dijkstra a réprimandé ses collègues pour avoir utilisé ce dernier terme car cest malhonnête, soutenant lidée que les fées des insectes pernicieuses et inconstantes ont planté des bogues dans nos programmes alors que nous ne cherchions 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 ne plus appeler un bogue un bogue mais en lappelant une erreur. Cest beaucoup plus honnête parce que cela met carrément le blâme là où il appartient, à savoir. avec le programmeur qui a commis lerreur. La métaphore animiste du bogue qui sest malicieusement introduite alors que le programmeur ne cherchait pas est intellectuellement malhonnête car elle déguise que lerreur est la propre création du programmeur. La bonne chose de ce simple changement de vocabulaire est quil a un effet si profond : alors quavant, un programme avec un seul bogue était « presque correct », ensuite un programme avec une erreur est juste « faux » (parce que dans lerreur).

Commentaires

• En fait, jaime le terme " error " plutôt que " bug ", pas parce que cela met le blâme sur " le programmeur qui a commis lerreur ", mais parce que cela indique clairement quil pourrait ne pas être le programmeur en faute. Pour moi, " bug " implique une erreur dans le code; alors que " erro r " implique une erreur quelque part . Peut-être dans le code, peut-être dans la configuration de lenvironnement, peut-être dans les exigences. Ça me rend dingue quand mon patron a une " liste de bogues " où la moitié des problèmes sont des changements dexigences. Appelez ça une liste de tâches, ferchrissakes!
• +1 pour " chaque erreur est une opportunité dapprendre, presque toujours sur vous-même (car seuls les débutants blâment le compilateur / lordinateur dabord) "
• Vous connaissez lhistorique du terme " bug ", non? Je veux dire, comme utilisé dans le développement de logiciels. Bien sûr, nous navons ' pas ce problème aujourdhui, mais un bogue a en fait pénétré dans le matériel dun ordinateur sans être remarqué par le programmeur et a causé un problème.De peur que quelquun ne pense me corriger, je sais quEdison a utilisé ce terme bien avant lincident du papillon de nuit, cest pourquoi jai utilisé le mot ' histoire ', pas ' origin '. Voir computerworld.com/article/2515435/app-development/… et en.wikipedia.org/wiki/Software_bug#Etymology
• @threed Bien sûr. Mais depuis un certain temps, les insectes nont pas causé la grande majorité des erreurs logicielles.

1. Ecrivez des tests. Les tests sont non seulement excellents pour prévenir les bogues (daprès mon expérience, le TDD bien fait élimine presque tous les bogues triviaux et stupides), mais aide également beaucoup au débogage. Les tests obligent votre conception à être plutôt modulaire, ce qui facilite grandement lisolement et la réplication du problème. De plus, vous contrôlez lenvironnement, donc il y aura beaucoup moins de surprises. De plus, une fois que vous obtenez un cas de test qui échoue, vous pouvez être raisonnablement sûr que vous « avez cloué la vraie raison du comportement qui vous dérange.

2. Apprenez à utiliser un débogueur. Les instructions print peuvent fonctionner raisonnablement bien à un certain niveau, mais un débogueur la plupart du temps est très utile (et une fois vous savez comment vous en servir, cest beaucoup plus confortable que les déclarations print).

3. Parlez de votre problème à quelquun, même si cest juste un canard en caoutchouc . Se forcer à exprimer le problème sur lequel vous travaillez avec des mots fait vraiment des miracles.

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

Commentaires

• +1 pour " Se forcer à exprimer le problème sur lequel vous travaillez avec des mots fait vraiment des miracles. "
• Et pour ajouter à (1), presque tous les bogues que vous voyez dans le code impliquent quil y a ' un bogue – ou du moins une omission – dans la suite de tests. Corrigez les deux en même temps et non seulement vous prouvez que ' avez résolu le problème, vous ' êtes en sécurité contre cela réintroduit.

Jaime la plupart des autres réponses, mais voici quelques conseils sur la marche à suivre AVANT de faire quoi que ce soit. Cela vous fera gagner beaucoup de temps.

1. Déterminez sil y a vraiment un bogue. Un bogue est TOUJOURS une différence entre le comportement du système et les exigences; le testeur doit être capable darticuler le comportement attendu et réel. Sil est incapable de fournir une assistance pour le comportement attendu, il ny a aucune exigence et il ny a pas de bogue – juste lopinion de quelquun. Renvoyez-le.

2. Envisagez la possibilité que le comportement attendu est incorrect. Cela peut être dû à une mauvaise interprétation de lexigence. Cela peut également être dû à un défaut dans lexigence elle-même (un delta entre une exigence détaillée et une exigence métier). Vous pouvez également les renvoyer.

3. Isolez le problème. Seule lexpé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 à varier une chose tout en garder toutes les autres choses constantes (le problème se produit-il sur dautres environnements? avec dautres navigateurs? dans une région de test différente? à différents moments de la journée?) Une autre approche consiste à regarder les vidages de pile ou les messages derreur – parfois vous pouvez dire juste par la façon dont il est formaté quel composant du système a jeté lerreur dorigine (par exemple, si cest en allemand, vous pouvez bla moi ce tiers avec lequel vous travaillez à Berlin).

4. Si vous lavez réduit à deux systèmes qui collaborent, inspectez les messages entre les deux systèmes via le moniteur de trafic ou les fichiers journaux , et déterminez quel système se comporte selon les spécifications et lequel ne lest pas. Sil y a plus de deux systèmes dans le scénario, vous pouvez effectuer des vérifications par paires et descendre dans la pile dapplications.

5. La raison pour laquelle lisolement du problème est si critique est que le problème nest peut-être pas dû à un défaut de code sur lequel vous avez le contrôle (par exemple, les systèmes tiers ou lenvironnement) et que vous souhaitez que cette partie prenne le relais le plus rapidement possible. Cest à la fois pour vous faire économiser du travail et pour les mettre immédiatement au point afin que la résolution puisse être obtenue dans un laps de temps aussi court que possible. Vous ne voulez pas travailler sur un problème pendant dix jours seulement pour trouver que cest vraiment un problème avec le service Web de quelquun dautre.

6. Si vous avez déterminé quil y a vraiment un défaut et que cest vraiment dans le code que vous contrôlez, vous pouvez isoler davantage le problème en recherchant la dernière version « connue en bon état » et inspecter les journaux de contrôle de source pour les changements qui peuvent avoir causé le problème. Cela peut gagner beaucoup de temps.

7. Si vous ne pouvez pas le comprendre à partir du contrôle de code source, il est maintenant temps de joindre votre débogueur et de parcourir le code pour le comprendre Il y a de fortes chances que vous ayez une assez bonne idée du problème de toute façon.

Une fois que vous savez où se trouve le bogue et que vous pouvez trouver une solution, voici « une bonne procédure pour y remédier:

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

2. Sans modifier le test unitaire, faites il réussit (en modifiant le code de lapplication).

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

Je pense que la reproduction dun bug est également importante. Tous les cas qui reproduisent le bogue peuvent être listés et vous pouvez ensuite vous assurer que votre correction de bogue couvre tous ces cas.

Jai lu un excellent livre sur ce sujet intitulé Pourquoi les programmes échouent , qui décrit diverses stratégies pour trouver des bogues allant de lapplication de la méthode scientifique pour isoler et résoudre un bug, au débogage delta. Lautre partie intéressante de ce livre est quil supprime le terme « bug ». Lapproche de Zeller est:

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

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

Dans ma propre expérience personnelle, jai trouvé beaucoup de bogues dans notre application, mais la direction nous pousse simplement à avancer pour obtenir de nouvelles fonctionnalités. Jai souvent entendu dire que « Nous avons trouvé ce bogue nous-mêmes et le client » ne la pas encore remarqué, alors laissez-le jusquà ce quil le fasse « . Je pense quêtre réactif par opposition à proactif dans la correction des bogues est une très mauvaise idée car lorsque le moment est venu de mettre un correctif, vous avez dautres problèmes qui doivent être résolus et plus de fonctionnalités de gestion veulent sortir dès que possible, alors vous êtes pris. dans un cercle vicieux qui peut entraîner beaucoup de stress et dépuisement professionnel et finalement, un système défectueux.

La communication est également un autre facteur lorsque des bogues sont détectés. Envoyer un e-mail ou le documenter sur le le traqueur de bogues est très bien, mais selon ma propre expérience, dautres développeurs trouvent un bogue similaire et plutôt que de réutiliser la solution que vous avez mise pour corriger le code (car ils ont tout oublié), ils ajoutent leurs propres versions, donc vous avez 5 solutions différentes dans votre code et il semble plus gonflé et déroutant en conséquence. Ainsi, lorsque vous corrigez un bogue, assurez-vous que quelques personnes examinent le correctif et vous donnent des commentaires au cas où ils auraient corrigé quelque chose de similaire et a trouvé une bonne stratégie pour y faire face.

limist a mentionné le livre,