Comment améliorer votre capacité à déboguer du code existant [fermé]

Une tâche courante dans le monde du travail consiste à gérer le code existant, mais bogué. Quels sont quelques conseils pour améliorer vos compétences en tant que débogueur?

Ne présumez rien

Il est souvent tentant de simplement dire "oh, je sais ce que fait ce morceau de code, ça va". Ne fais pas ça. Testez chaque hypothèse et parcourez tout attentivement.

Test incrémentiel .

Allez d'abord en profondeur dans votre code et testez-le à partir du plus petit module en remontant progressivement. De cette façon, vous n'êtes pas trop stressé pour essayer de comprendre où le problème pourrait être exactement.

Cela signifie également que cela affecte moins de code à la fois car vous vous déplacez de manière incrémentielle ... comme parfois, j'ai eu des problèmes où j'ai corrigé quelque chose et cela a conduit à casser beaucoup d'autres choses. Je donne du crédit à mon patron pour cela car il m'a appris cela quand je me suis amusé.

Diviser pour mieux régner est une bonne approche. Essayez d'identifier une entrée visible (entrée utilisateur / événement réseau ...) et une sortie (journal, sortie utilisateur, message réseau sortant ...) entre lesquelles le problème existe. Essayez de placer des tirages sur des segments importants ou des points significatifs entre eux et essayez de réduire la position du bogue dans le code.

Diviser pour mieux régner peut également très bien fonctionner en cas de régression sur du code contrôlé par version. Trouvez deux versions - une où cela fonctionne comme prévu, l'autre avec la régression. Réduisez l'écart jusqu'à ce que vous vous retrouvez avec un tas de checkins en tant que suspects potentiels.

Plutôt que de couper les bogues binaires, écrivez des tests sous la forme

• Donné...
• Quand...
• Attendre...

Pour vérifier ce que vous savez réellement sur le fonctionnement de l'application par rapport à ce que vous supposez être vrai.

La plupart des IDE facilitent l'extraction de méthodes et la génération de stubs de test xUnit. Profitez-en.

Pourquoi ne pas saupoudrer les débogages? Parce qu'après avoir terminé, vous devrez probablement annuler une grande partie de ce travail et supprimer une bonne partie de ces débogages. Lorsque vous écrivez des tests, votre débogage contribuera à la prévention et à la détection de futurs bogues.

Continuez à déboguer. Si vous déboguez beaucoup, vous vous améliorerez.

Comme d'autres l'ont dit - n'assumez rien. Cela est particulièrement vrai si vous avez écrit son code. Lorsque vous déboguez d'autres codes, vous êtes plus susceptible de ralentir car le code est nouveau pour vous ou vous ne faites pas confiance au codeur. Lorsque vous déboguez votre propre code, il est trop facile de supposer que vous l'avez écrit correctement, ralentissez!

Pour le processus réel de débogage:

• Écrivez des tests unitaires s'ils n'existent pas déjà.
• Ajoutez une journalisation appropriée si elle n'existe pas déjà.
• Utilisez ensuite le débogage.

L'ajout des tests unitaires et la journalisation sont plus efficaces que l'utilisation du débogueur en premier. Vous bénéficiez également de l'avantage supplémentaire d'avoir les tests unitaires pour éviter d'introduire de futurs bogues et la journalisation aidera à déboguer les sessions à l'avenir.

Avant de franchir un petit morceau de code, voyez si vous pouvez déterminer avec précision le résultat. Cela a tendance à ne pas supposer quoi que ce soit (que j'ai voté BTW), mais à mesure que vous acquérez de l'expérience, cela peut aider à préciser où chercher.

Cela peut sembler trivial, mais apprenez les nuances de votre débogueur et apprenez les raccourcis clavier. Parfois, les débogueurs peuvent être suffisamment lents pour que votre esprit se demande quand vous passez à travers. Si vous pouvez suivre la machine et ne pas vous déplacer, cela peut vous aider.

Si vous pouvez modifier le code pendant le débogage:

• envisager d'affirmer les conditions pré ET post. Parfois, vous pouvez ensuite passer au-dessus du code.
• car si les déclarations avec des expressions compliquées, pensez à quelque chose (certains peuvent froncer les sourcils, mais cela fonctionne pour moi)

comme:

bool isLessThan5 = a < 5;
bool isGreaterThan10 = a > 10;
if ( isLessThan5 || isGreaterThan10 )
{
   // more code here
}

au lieu de:

if ( a < 5 || a > 10 )
{
   // more code here
}

Pour les cas où vous ne pouvez pas tout déboguer, pour quelque raison que ce soit, apprenez à "canard en caoutchouc" avec un collègue. Parfois, le fait d'expliquer fait la lumière. (ok, peut-être que ce n'est pas exactement dans le thème des questions, mais je pense qu'il est assez proche pour mériter d'être mentionné)

Deux choses, basées sur la plupart des 22 dernières années passées à maintenir le code écrit par d'autres personnes.

Comprenez les types de bogues que vous avez tendance à écrire.

Par exemple, je suis un codeur très méticuleux, donc une fois que mon code est compilé, il est généralement exempt de bugs triviaux. Donc, mes bugs ont tendance à être des choses compliquées étranges comme les blocages de threads. D'un autre côté, j'ai un ami qui écrit principalement des bogues triviaux - des points-virgules à la fin de C ++ pour les boucles, donc la ligne suivante n'est exécutée qu'une seule fois, ce genre de chose.

Ne présumez pas que d'autres personnes écrivent le même genre de bogues que vous.

Je ne sais pas combien de fois j'ai perdu du temps à retirer les gros pistolets de débogage, en supposant qu'un bug était mon genre de chose vraiment subtile, juste pour que mon ami regarde par-dessus mon épaule et dise: "Avez-vous remarqué cet extra point-virgule? " Après des années, je vais d'abord chercher les fruits triviaux et bas quand je regarde le code des autres.

Connaissez vos outils. Par exemple, le débogueur de Visual Studio a une fonctionnalité impressionnante appelée TracePoints qui sont comme des points d'arrêt mais au lieu d'arrêter votre code à la place, insère une instruction de trace dans la sortie de débogage.

Lire des livres ou suivre un cours sur l'utilisation de votre débogueur est fortement recommandé. J'ai pris quelques cours et lu quelques livres de John Robbins qui ont fait une grande différence dans mon efficacité en tant que débogueur.

Comprendre fonctionnellement ce que le code essaie de faire. Si vous ne connaissez pas l'image complète (tous les cas de test ce code doit passer), il est difficile de déboguer correctement sans introduire de nouveaux bogues

Rédiger des tests unitaires automatisés et d'autres types de tests d'intégration et fonctionnels.

Plus vous avez de tests automatisés, moins vous devez passer de temps dans un débogueur.

Aussi, bonne conception - principes SOLIDES. Si vous écrivez de petites classes ciblées et privilégiez la composition plutôt que l'héritage, en éliminant la duplication, etc., votre code sera toujours plus facile à déboguer.

Je trouve que le code bien conçu produit un ensemble différent de bogues que le code n'est pas bien conçu. De manière générale, un code bien conçu produit des bogues plus faciles à trouver, à reproduire et à corriger.

L'exception (et il y en a toujours une) est le code multithreading :-)

Si vous l'avez réduit à une petite région, mais que vous ne parvenez toujours pas à détecter l'erreur, essayez l'option `` afficher le code + l'assemblage '' de votre débogueur. Connaître suffisamment ASM pour dire "il devrait y avoir une branche ici" ou "pourquoi ne fait-il que copier le mot bas?" identifiera souvent l'erreur de codage.

Consultez le très précieux livre Why Programs Fail: A Guide to Systematic Debugging , par Andreas Zeller. Il vous présentera de nombreuses techniques, théories et outils, dont certains sont à la pointe de la recherche.

Les diapositives du livre sont disponibles en ligne, mais je trouve que le livre lui-même est plus facile à lire.

Le livre vous aidera à démarrer et à vous faire réfléchir plus scientifiquement sur le débogage, mais il ne remplace pas la pratique. Vous devrez peut-être écrire et déboguer pendant 10 ans avant de constater un ordre de grandeur d'amélioration de vos performances. Je me souviens encore que ma mâchoire était tombée chez Sun. L'expérience compte!