Le code de débogage doit-il être laissé en place, toujours ou ajouté uniquement lors du débogage et supprimé lorsque le bogue a été trouvé?


35

Pour ma part, je n’ajoute du code de débogage (tel que des instructions print) lorsque je tente de localiser un bogue. Et une fois que je l'ai trouvé, je supprime le code de débogage (et ajoute un scénario de test qui teste spécifiquement ce bogue). Je sens que cela encombre le vrai code et n’a donc pas sa place à moins que je ne débogue.

Comment faites-vous? Laissez-vous le code de débogage en place ou le supprimez-vous lorsqu'il est obsolète (ce qui peut être difficile à déterminer quand)?

Réponses:


30

Les instructions d'impression de débogage doivent être supprimées. Cependant, si vous avez besoin de les ajouter pour résoudre un problème de production, il peut être intéressant de considérer si vous avez suffisamment d'informations insérées dans votre cadre de journalisation. Les informations sur les paramètres, les conditions d'erreur, etc. peuvent s'avérer utiles ultérieurement, lors de l'apparition du prochain bogue. L'utilisation d'une bonne infrastructure de journalisation pouvant activer dynamiquement les messages de journal de suivi ou de débogage peut s'avérer très utile dans la nature.


5
+1 Principalement pour avoir mis en place un cadre de débogage sensible. Si cela est en place au départ et s'il existe différents niveaux de débogage, le code de production peut normalement s'exécuter sans appeler de routines de débogage coûteuses, et le code de développement peut être exécuté avec le niveau de contrôle requis, éventuellement enregistré dans la méthode souhaitée.
Orbling

1
D'accord avec Orbling. Et en plus, pour le code de débogage autre que le seul affichage d'informations ayant un impact sur les performances ou pour toute autre raison impropre à la production. (par exemple, une assertion sur le résultat d'une fonction, par exemple, la vérification du résultat d'un tri), vous pouvez envisager deux modes de construction cible. mode débogage et mode libération.
Zekta Chan

16

Le code ajouté spécifiquement pour le débogage doit être supprimé du logiciel de production.

Qu'il s'agisse d'une suppression complète ou d'être inséré dans des sections de compilation conditionnelle (comme en C / C ++ / C #), cela dépend de vous et de votre norme de codage.

Il ya un certain nombre de raisons à cela:

  1. Il pourrait y avoir des problèmes de sécurité si ce code est exécuté ou si quelqu'un peut accéder à sa sortie.
  2. Cela pourrait ralentir l'application.
  3. Cela pourrait être déroutant pour les autres développeurs qui regardent le code (ou même vous-même) dans les 6 mois à venir.

+1 pour la compilation conditionnelle, mais les blocs de commentaires fonctionneront dans des langues qui ne les prennent pas en charge. Vous ne devriez jamais le laisser compilé dans une version de prod, mais il est parfois excessivement inefficace de continuer à la supprimer entièrement à chaque fois que vous souhaitez supprimer une version validée.
Bill le

1
J'ai travaillé dans des environnements où le code C / C ++ était toujours compilé avec des options de débogage au cas où le code de production devait être débogué ou si un coredump était examiné. Parfois, ce mandat toujours prêt à déboguer nécessitait de laisser des instructions de débogage afin de pouvoir les activer avec un indicateur sans recompiler le code. Java autorise toujours le débogage si les options de votre machine virtuelle Java sont définies pour cette tâche, ce qui nécessite relativement moins de travail de préparation.
Michael Shopsen

16

ChrisF et Alaric ont tous deux des points valables. +1 pour eux. Je peux identifier au moins 5 types de code de débogage différents que j'utilise.

  1. Utilisation des journaux pour vider l’état du système à un moment donné.

    void function(...)
    {
        ...dump everything i know about.
    }
    
  2. Utilisation de journaux pour les points de contrôle d'exécution.

    void function(...)
    {
        ...got here 1
        ...got here 2
    }
    
  3. Code qui oblige une condition à être vraie, mais qui rompt avec un comportement normal. Exemple:

    • Supposons que vous ayez des journaux relatifs à une erreur, mais que vous ne pouvez pas reproduire le problème. Vous pouvez essayer d’écrire du code qui force certaines variables à avoir certaines valeurs correspondant aux informations du journal.
  4. Journalisation de vérification - Je classerais cela comme une journalisation détaillée pouvant être utilisée pour valider l'exactitude du logiciel qui ne devrait pas être incluse dans la production, comme la validation des étapes individuelles d'un algorithme, par exemple.

  5. Enregistrement des opérations - reportez-vous au message d’ Alaric . C'est à peu près ce que je veux dire par "enregistrement des opérations".

1, 2 et 3 devraient être complètement éliminés. Quelque chose comme 4, je compilerais sans condition conditionnellement hors du code. Pour 5, Alaric avait un grand intérêt à pouvoir désactiver dynamiquement les journaux. Cela peut répondre au point de ChrisF dans son deuxième point dans la plupart des cas.


1
C'est un bon résumé. Cependant, il serait préférable que vous puissiez le formater correctement en remplaçant 1)… par 1.… (afin que le formatage Markdown le prenne en tant que listes) et en indentant le code de l'exemple de 8 espaces (de nouveau, de sorte que Markdown le prenne comme exemple code dans une liste).
Konrad Rudolph

@ Konrad Rudolph: Fait.
Gablin

3

Cela dépend de ce que le code fait. Certains codes utilisés pour le débogage peuvent être laissés tels quels et certains doivent être supprimés.

Le code qui vérifie la validité des paramètres dans une méthode n'est pas toujours utile une fois que le code fonctionne correctement, mais il est souvent conservé pour s'assurer que le code continue à fonctionner correctement.

Parfois, vous écrivez du code différemment pour faciliter le débogage du code, par exemple en calculant une valeur et en l'insérant dans une variable locale, puis en utilisant la variable de la ligne suivante, ce qui facilite la vérification du résultat du calcul en mode pas à pas. à travers le code. Vous pouvez réécrire le code pour utiliser directement la valeur calculée, mais le coût d'utilisation de la variable locale est si faible (le cas échéant) qu'il n'y a aucune raison de le réécrire. De même, si vous laissez le code inchangé une fois que vous l'avez testé, il est toujours possible que vous introduisiez un bogue lors de sa modification.

Le code que vous ajoutez uniquement pour localiser un bogue spécifique peut souvent être supprimé une fois que vous avez trouvé le bogue.


2

Il était une fois, j’utilisais beaucoup de code de débogage. Je ciblais presque entièrement Windows, il y avait donc beaucoup de cette fonction de sortie de chaîne de débogage dont je ne me souviens plus comment épeler, pour pouvoir capturer la trace avec un programme particulier.

Certains codes de débogage sont restés en place, notamment des éléments destinés à imbriquer des appels. Cependant, même si la chaîne de débogage ne serait généralement pas visible sur un système de production, elle était toujours réalisée sous une compilation conditionnelle.

La réalité est cependant que tout ce code de débogage demandait beaucoup d'effort pour quelque chose idéalement géré différemment - en utilisant, bien sûr, un débogueur. À l'époque, le débogueur C ++ de Borland ne m'impressionnait pas autant. Les outils étaient là, mais ils donnaient trop souvent des résultats trompeurs et utiliser le débogueur non-IDE (souvent nécessaire) signifiait mémoriser les touches de raccourci, ce qui distrayait le travail à accomplir.

La seule expérience de débogage que j'ai trouvée qui soit pire est celle de GDB en ligne de commande.

Bien sûr, il est important d’être un expert des outils que vous utilisez tous les jours. Cependant, le débogage ne devrait pas être une chose à faire tous les jours. Si vous utilisez le débogueur si souvent que vous êtes prêt à apprendre des dizaines de commandes et / ou de raccourcis clavier, cela me semble un peu rouge.

Au moment où je travaillais dans Visual Studio 7, il était clair que le débogage pouvait être très pratique et efficace. Si vous pouvez effectuer le débogage dans Visual Studio (éditions express incluses), le débogage est un jeu d'enfant. Nul doute que si vous pouvez trouver le bon frontal GUI / IDE, GDB est simple et efficace, même si je n’ai pas encore fait cette recherche.

Il y a aussi quelque chose à dire pour les tests unitaires, avec une analyse de couverture utilisant gcov. Plus vous êtes confiant dans le comportement de vos bibliothèques, moins votre débogage doit être approfondi - et moins vous avez besoin du débogueur en premier lieu. Et écrire des tests unitaires est tout à fait raisonnablement quelque chose que vous devriez faire la plupart des jours.

Outil inopinément important = cmake, un outil de construction qui me permet de basculer facilement entre la construction de GCC et celle de VC ++, entre autres choses. Donc, je peux faire mes tests unitaires et ma couverture basée sur gcov en utilisant GCC, mais basculer facilement vers VC ++ pour utiliser le débogueur.


Un débogueur peut être très inutile sinon dangereux dans les applications multithreads, mais j'aime votre commentaire flagrant.
Pemdas

@Pemdas - Je n'ai pas encore rencontré de problème sérieux dans ce sens, même si le multi-threading n'est évidemment pas adapté au débogueur. Malgré tout, je pense que les bons outils sont probablement une meilleure solution que le code de débogage en principe. Un outil d’analyse statique qui peut repérer les conditions de concurrence, les blocages, les conditions dans lesquelles deux threads peuvent se disputer la même mémoire / ressource en même temps, etc. serait bien. Je n'ai aucune idée de ce qui est disponible dans ce sens, même si je sais qu'il existe des outils intelligents. Klee, par exemple - je ne le comprends pas, mais la description de base est très impressionnante.
Steve314

"Je pense que les bons outils sont probablement une meilleure solution que le code de débogage en principe" C'est une déclaration dangereuse;). Avoir des outils préformant une partie de l'analyse pourrait être bien, mais je crains que les développeurs, en particulier les nouveaux, ne deviennent trop dépendants des outils, comme quelqu'un qui doit utiliser une calculatrice pour comprendre ce que sont 15% des 100%.
Pemdas

Devenir trop dépendant d'outils que je n'ai même pas encore recherchés me semble peu probable. Sur votre exemple de calculatrice, oui, mais j'utiliserai toujours OpenOffice Calc plutôt que d'écrire mon propre tableur. Il y a un temps pour le code de débogage (même avec un débogueur - par exemple votre propre cas créant des conditions bizarres), mais s'il dépasse un certain point, les outils existants gagnent. Et lorsqu'il s'agit de soustraire 15% de 115, j'utiliserai aussi cette calculatrice - ce que beaucoup de gens donneraient comme réponse évidente (100) est fausse. En multithreading, il est évident que les bonnes réponses sont tristement célèbres, car elles s'avèrent parfois fausses.
Steve314

1

Mon point de vue: le code de débogage utilisé pour tuer un bogue dans le code en question que je supprime généralement entièrement. Le code de débogage utilisé pour supprimer un bogue résultant de forces extérieures est généralement simplement commenté.


-1

Si le bogue provient de l'unité de test ou de l'interne, le code de débogage peut être complètement supprimé. Mais si le bogue provient de la production, le code de débogage doit être placé dans les balises de compilation. Le placer dans des balises de compilation aidera les autres développeurs à comprendre que ce code est uniquement destiné au débogage.


-1

Utilisez TDD pour que votre code de test ait toujours un endroit où il est même maintenu.


Comment cela répond-il à la question posée?
moucher

Parce que TDD vous conduit à "déboguer" ou à tester du code que vous n'avez pas à supprimer.
dukeofgaming

Je ne suis pas désolé. Comment c'est?
moucheron
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.