Comment améliorer votre capacité à déboguer du code existant [fermé]
29
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?
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.
+1. Absolument. Préparez-vous à être étonné de voir comment certaines choses, vous pensiez le savoir, vont vous jouer des tours.
aufather
fonctionne pour moi :)
setzamora
3
Déboguer le code d'un autre est une perte de temps énorme, une perte de productivité, mais c'est comme ça. Le seul moment où il est vraiment logique de corriger les bugs des autres est quand ils sont partis. Ce que je déteste, je déteste, passe par un code objectivement merdique par un codeur senior, puis doit poser une question afin de progresser en temps opportun et obtenir une conférence sur l'amélioration de mes compétences pour apprendre la base de code existante. Contrairement à l'étude de la mère nature, la résolution des ratés causés par l'homme n'est guère amusante. Au moins, j'obtiens ma réponse. La situation inverse ne se produira pas, car je vais juste mieux et laisse moins de bugs.
Job
1
@Job: ... d'accord? Vouliez-vous laisser ce commentaire sur le post, peut-être? :)
Adam Lear
Cette! Il est stupide de faire aveuglément confiance à un petit morceau de votre code si vous déboguez un problème étrange et que le code semble correct.
Dan
7
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.
Le débogage est absolument dans l'art en soi, en particulier le débogage du code d'autres peuples.
Gratzy
2
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é)
La dénomination des sous-conditions nécessite une étape supplémentaire, à savoir la refactorisation des noms lorsque vous découvrez à quoi sert la condition. Cela pourrait se révéler if (tooCloseToHydrant || overTheBrink) { lorsque vous en apprendrez plus tard.
1
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.
Reformatez-vous le code pour voir si quelque chose bouge?
@ Thorbjørn: Si j'ai pris possession du code, je le fais parfois pour améliorer la lisibilité, mais pas pour trouver des fautes de frappe. Idée intéressante!
Bob Murphy
vous n'avez pas à le commettre, voyez ce qui se passe. Je peux fortement recommander d'appliquer une politique qui nécessite un reformatage du code - de préférence automatiquement - lors de l'enregistrement.
@ Thorbjørn: J'adorerais faire ça. Que recommandez-vous comme code "prettifier"? Je travaille principalement sur Linux et Mac.
Bob Murphy
J'utilise Eclipse disponible aux deux endroits, et l'éditeur Java a une action dite d'enregistrement où vous pouvez spécifier ce qui doit se produire à chaque fois que le fichier est enregistré. Ici, l'une des options consiste à formater la source. Nous sommes une petite équipe donc je n'ai pas approfondi la question. Des équipes plus expérimentées autorisent les hooks de pré-validation dans les systèmes de contrôle de source, ce qui permet de rejeter une validation de source si elle est incorrectement formatée. Très efficace.
1
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!
Réponses:
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.
la source
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é.
la source
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.
la source
Plutôt que de couper les bogues binaires, écrivez des tests sous la forme
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.
la source
Continuez à déboguer. Si vous déboguez beaucoup, vous vous améliorerez.
la source
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:
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.
la source
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:
comme:
au lieu de:
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é)
la source
if (tooCloseToHydrant || overTheBrink) {lorsque vous en apprendrez plus tard.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.
la source
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.
la source
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
la source
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 :-)
la source
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.
la source
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!
la source