Pourquoi le débogage est-il meilleur dans un IDE?
Je suis développeur de logiciels depuis plus de vingt ans, programmant en C, Perl, SQL, Java, PHP, JavaScript et récemment Python. Je n'ai jamais eu de problème que je ne pouvais pas déboguer en utilisant une réflexion approfondie et des instructions de débogage print bien placées.
Je respecte le fait que beaucoup de gens disent que mes techniques sont primitives, et utiliser un vrai débogueur dans un IDE est beaucoup mieux. Pourtant, d'après mon observation, IDE utilisateurs don ne semblent pas déboguer plus rapidement ou avec plus de succès que je ne peux, en utilisant mes couteaux en pierre et mes peaux d'ours.
De plus, je n'ai jamais lu un tutoriel ou un livre qui montre comment déboguer efficacement en utilisant un IDE, au-delà des bases de la façon de définir des points d'arrêt et d'afficher le contenu des variables.
Qu'est-ce que je rate? Qu'est-ce qui rend les outils de débogage IDE tellement plus efficaces que l'utilisation réfléchie des instructions de diagnostic print?
Pouvez-vous suggérer des ressources (tutoriels, livres, screencasts) qui montrent les techniques plus fines du débogage IDE?
Douces réponses! Merci beaucoup à tous d'avoir pris le temps. Très éclairant. J'en ai voté beaucoup et n'en ai voté aucun.
Quelques points notables:
- Les débogueurs peuvent m'aider à faire ad hoc inspection ou altération des variables, du code ou de tout autre aspect de l'environnement d'exécution, tandis que le débogage manuel m'oblige à arrêter, éditer et ré-exécuter l'application (nécessitant éventuellement recompilation).
- Les débogueurs peuvent s'attacher à un processus en cours ou utiliser un vidage sur incident, alors qu'avec le débogage manuel, des "étapes pour reproduire" un défaut sont nécessaires.
- Les débogueurs peuvent afficher des structures de données complexes, des environnements multithreads ou des piles d'exécution complètes facilement et de manière plus lisible.
- Les débogueurs offrent de nombreuses façons de réduire le temps et le travail répétitif pour effectuer presque toutes les tâches de débogage.
- Les débogueurs visuels et les débogueurs de console sont tous deux utiles et ont de nombreuses fonctionnalités en commun.
- Un débogueur visuel intégré dans un IDE vous donne également un accès pratique à l'édition intelligente et à toutes les autres fonctionnalités de l'IDE, dans un seul environnement de développement intégré (d'où le nom).
Quelques exemples de certaines capacités qu'un débogueur IDE vous fournira des messages de trace dans le code:
- Affichez la pile d'appels à tout moment, vous donnant un contexte pour votre cadre de pile actuel.
- Entrez dans les bibliothèques que vous n'êtes pas en mesure de recompiler dans le but d'ajouter des traces (en supposant que vous avez accès aux symboles de débogage)
- Modifier les valeurs des variables pendant l'exécution du programme
- Modifier et continuer - la possibilité de changer le code pendant qu'il est en cours d'exécution et voir immédiatement les résultats du changement
- Être capable de regarder variables, voir quand elles changent
- Être capable de sauter ou répéter des sections de code, pour voir comment le code fonctionnera. Cela vous permet de tester les modifications théoriques avant de les effectuer.
- Examiner contenu de la mémoire en temps réel
- Vous alerter lorsque certaines exceptions sont levées, même si elles sont gérées par l'application.
- Point d'arrêt conditionnel; l'arrêt de l'application uniquement dans des circonstances exceptionnelles pour vous permettre d'analyser la pile et les variables.
- Affichez le contexte de thread dans les applications multi-thread, ce qui peut être difficile à réaliser avec le traçage (car les traces de différents threads seront entrelacées dans la sortie).
En résumé, les instructions d'impression sont (généralement) statiques et vous devrez recompiler pour obtenir des informations supplémentaires si vos instructions originales n'étaient pas suffisamment détaillées. . Le IDE supprime cette barrière statique, vous donnant une boîte à outils dynamique à portée de main.
Quand j'ai commencé à coder, je ne pouvais pas comprendre quel était le problème avec les débogueurs et je pensais que je pouvais tout faire avec le traçage (d'accord, c'était sur unix et le débogueur était GDB). Mais une fois que vous avez appris à utiliser correctement un débogueur graphique, vous ne voulez plus revenir aux instructions d'impression.
Un débogueur IDE vous permet de modifier les valeurs des variables au moment de l'exécution.
Un débogueur IDE vous permet de voir la valeur des variables que vous ne saviez pas que vous vouliez voir lorsque l'exécution a commencé.
Un débogueur IDE vous permet de voir la pile d'appels et d'examiner l'état de la fonction a passé des valeurs étranges. (Pensez que cette fonction est appelée à partir de centaines d'endroits, vous ne savez pas où sont ces valeurs étranges) provenir de)
Un débogueur IDE vous permet d'interrompre conditionnellement l'exécution à tout moment dans le code, en fonction d'une condition, et non d'un numéro de ligne.
Un débogueur IDE vous permettra d'examiner l'état du programme dans le cas d'une exception non gérée au lieu de simplement craquer.
Voici une chose que vous ne pouvez certainement pas déboguer avec l'instruction "print", qui est lorsqu'un client vous apporte un vidage de mémoire et dit "votre programme s'est écrasé, pouvez-vous me dire pourquoi?"
- L'impression des instructions tout au long de votre code réduit la lisibilité.
- Les ajouter et les supprimer uniquement à des fins de débogage prend du temps
- Les débogueurs suivent la pile des appels, ce qui vous permet de voir facilement où vous êtes
- Les variables peuvent être modifiées à la volée
- Les commandes ad hoc peuvent être exécutées pendant une pause dans l'exécution pour aider au diagnostic
- Peut être utilisé EN CONJONCTION avec des instructions d'impression: Debug.Write ("...")
Je pense que le débogage à l'aide d'instructions d'impression est un art perdu et très important pour chaque développeur. Une fois que vous savez comment faire cela, certaines classes de bogues deviennent beaucoup plus faciles à déboguer de cette façon que via un IDE. Les programmeurs qui connaissent cette technique ont également une très bonne idée des informations utiles à mettre dans un message de journal (sans oublier que vous finirez par lire le journal) à des fins de non-débogage.
Cela dit, vous devez vraiment savoir comment utiliser le débogueur pas à pas, car pour une classe de bogues différente, c'est bien plus facile. Je laisse le soin aux autres excellentes réponses déjà publiées pour expliquer pourquoi :)
Du haut de ma tête:
- Débogage d'objets complexes - Les débogueurs vous permettent de pénétrer profondément dans les entrailles d'un objet. Si votre objet possède, par exemple, un tableau de tableaux d'objets complexes, les instructions d'impression ne vous permettront que de vous déplacer jusqu'à présent.
- La possibilité de dépasser le code - Les débogueurs vous permettront également d'ignorer le code que vous ne voulez pas exécuter. Certes, vous pouvez également le faire manuellement, mais c'est beaucoup plus de code que vous devez injecter.
Comme alternative au débogage dans IDE vous pouvez essayer grand Google Chrome console PHP avec bibliothèque php qui permet de:
- Voir les erreurs et les exceptions dans Chrome console JavaScript et dans les fenêtres de notification.
- Vider n'importe quelle variable de type.
- Exécutez PHP code à distance.
- Protégez l'accès par mot de passe.
- Grouper les journaux de console sur demande.
- Aller au fichier d'erreur: ligne dans votre éditeur de texte.
- Copiez les données d'erreur/de débogage dans le presse-papiers (pour les testeurs).
Je n'ai pas développé depuis près de 20 ans, mais je trouve qu'en utilisant un IDE/debugger je peux:
- voir toutes sortes de choses que je n'aurais pas pensé avoir incluses dans une déclaration imprimée
- parcourir le code pour voir s'il correspond au chemin que je pensais qu'il faudrait
- définir des variables à certaines valeurs pour que le code prenne certaines branches
L'une des raisons d'utiliser le IDE peut être que les IDE modernes prennent en charge plus que de simples points d'arrêt. Par exemple, Visual Studio offre les fonctionnalités de débogage avancées suivantes:
- définir des points d'arrêt conditionnels (interrompre uniquement si une condition est remplie, ou uniquement à la n-ième fois que l'instruction au point d'arrêt est exécutée)
- pause sur une exception non gérée ou chaque fois qu'une ecxeption (spécifique) doit être lancée
- changer de variable pendant le débogage
- répéter un morceau de code en définissant la ligne suivante à exécuter
- etc.
De plus, lorsque vous utilisez le débogueur, vous n'aurez pas à supprimer toutes vos instructions d'impression une fois le débogage terminé.
Une chose que je suis surpris de ne pas avoir vu dans une autre réponse est que les 2 méthodes de débogage sont ne s'excluent pas mutuellement.
printf le débogage peut très bien fonctionner même si vous utilisez un débogueur standard (que ce soit IDE basé ou non). En particulier avec un cadre de journalisation pour que vous puissiez laisser tout ou partie dans le produit commercialisé pour aider à diagnostiquer les problèmes des clients.
Comme indiqué dans à peu près toutes les autres réponses ici, le principal avantage d'un débogueur standard est qu'il vous permet d'examiner plus facilement (et éventuellement de modifier) les détails de l'état du programme. Vous n'avez pas besoin de savoir à l'avance ce que vous voudrez peut-être regarder - tout est disponible à portée de main (plus ou moins).
D'après mon expérience, les impressions simples ont un énorme avantage que personne ne semble mentionner.
Le problème avec un débogueur IDE est que tout se passe en temps réel. Vous arrêtez le programme à un certain moment, puis vous parcourez les étapes une par une et il est impossible de revenir en arrière si vous voulez soudainement voir ce qui s'est passé auparavant. Ceci est complètement en contradiction avec le fonctionnement de notre cerveau. Le cerveau recueille des informations et forme progressivement une opinion. passé un certain point, vous ne pouvez pas revenir en arrière.
Contrairement à cela, une série sélectionnée d'impressions/journalisation vous donne une "projection spatiale des événements temporels". Il vous donne une histoire complète de ce qui s'est passé, et vous pouvez revenir en arrière et quatrième plusieurs fois très facilement en il suffit de faire défiler vers le haut et vers le bas. Il est facile de répondre à des questions comme "est-ce que A s'est produit avant que B ne se produise". Il peut vous faire voir des modèles que vous ne cherchiez même pas.
Donc, selon mon expérience. IDE et les débogueurs sont des outils fantastiques pour résoudre des problèmes simples lorsque quelque chose dans une seule pile d'appels s'est mal passé, et explorer l'état actuel de la machine lors d'un certain crash.
Cependant, lorsque nous abordons des problèmes plus difficiles où un changement progressif d'état est impliqué. Par exemple, lorsqu'un algorithme a corrompu une structure de données, cela a provoqué l'échec d'un algorithme. Ou si nous voulons répondre à des questions comme "à quelle fréquence cela se produit-il", "les choses se passent-elles dans l'ordre et de la manière que j'imagine qu'elles se produisent". etc. La technique de consignation/impression "à l'ancienne" présente alors un net avantage.
La meilleure chose à faire est d'utiliser l'une ou l'autre technique quand elle est la plus appropriée, par exemple utiliser la journalisation/les impressions pour arriver à certains bugs, et faire une pause à un point d'arrêt où nous devons explorer l'état actuel plus en détail.
Il existe également des approches hybrides. Par exemple, lorsque vous faites console.log (objet), vous obtenez un widget de structure de données dans le journal que vous pouvez développer et explorer plus en détail. C'est souvent un avantage évident par rapport à un journal de texte "mort".
C'est ce que j'utilise le plus sur les fenêtres de débogage VS.NET:
- Pile d'appels, qui est également un excellent moyen de comprendre le code de quelqu'un d'autre
- Locaux et montres.
- Fenêtre immédiate, qui est essentiellement une console C # et me permet également de modifier le contenu des variables, d'initialiser des choses, etc.
- La possibilité de sauter une ligne, de définir la prochaine instruction à exécuter ailleurs.
- La possibilité de survoler les variables et d'avoir une info-bulle me montrant leurs valeurs.
En résumé, cela me donne une vue à 360 degrés de l'état de mon code d'exécution, pas seulement une petite fenêtre.
Je n'ai jamais trouvé de livre qui enseigne ce genre de choses, mais là encore, cela semble assez simple, c'est à peu près WYSIWYG.
Parce que le débogage d'applications multi-thread avec des instructions d'impression vous conduira à des bananes. Oui, vous pouvez toujours le faire avec des instructions d'impression mais vous en auriez besoin de beaucoup et démêler l'impression séquentielle des instructions pour émuler l'exécution multithreadg prendrait beaucoup de temps.
Malheureusement, les cerveaux humains ne sont que d'un seul fil.
Avantages d'un débogueur sur un printf (not not an IDE debugger but any debugger)
Peut définir des points d'observation. C'est l'une de mes façons préférées de trouver des corruptions de mémoire
Peut déboguer un binaire que vous ne pouvez pas recompiler pour le moment
Peut déboguer un binaire qui prend beaucoup de temps à recompiler
Peut changer des variables à la volée
Peut appeler des fonctions à la volée
N'a pas le problème où les statemenets de débogage ne sont pas vidés et donc le problème de synchronisation ne peut pas être débogué avec précision
Les débogueurs aident avec les vidages de mémoire, les instructions d'impression ne le font pas '
Depuis que vous avez demandé des pointeurs vers des livres ... En ce qui concerne le débogage Windows, John Robbins a plusieurs éditions d'un bon livre sur le débogage Windows:
Débogage d'applications pour Microsoft .NET et Microsoft Windows
Notez que l'édition la plus récente ( Débogage des applications Microsoft .NET 2. ) est .NET uniquement, vous pouvez donc en vouloir une plus ancienne (comme dans le premier lien) si vous voulez un débogage de code natif (il couvre les deux .NET et natif).
Personnellement, je pense que la réponse est aussi simple que "Un débogueur/IDE intégré vous donne une multitude d'informations différentes rapidement sans avoir besoin de saisir des commandes. Les informations ont tendance à être là devant vous sans que vous ne leur disiez quoi te montrer.
Le facilité dans lequel les informations peuvent être récupérées est ce qui les rend meilleures que le débogage en ligne de commande ou le débogage "printf".
En plus de ce que les autres affiches ont dit, j'aime vraiment parcourir une ligne à la fois avec l'ordinateur, car cela me force à penser à une ligne à la fois. Souvent, je vais attraper le bogue sans même regarder les valeurs des variables simplement parce que je suis obligé de le regarder lorsque je clique sur le bouton 'ligne suivante'. Cependant, je ne pense pas que ma réponse vous aidera, Bill, car vous avez probablement déjà cette compétence.
En ce qui concerne les ressources d'apprentissage, je n'en ai utilisé aucune - j'explore simplement tous les menus et options.
J'ai utilisé à la fois des impressions et des IDE pour le débogage et je préfère de beaucoup déboguer en utilisant un IDE. Le seul moment pour moi lorsque cela ne fonctionne pas est dans des situations critiques (comme le débogage de jeux en ligne) où vous jetez le code avec des instructions d'impression, puis regardez les fichiers journaux après qu'il a horriblement mal tourné. Ensuite, si vous ne pouvez toujours pas le comprendre, ajoutez plus d'impressions et répétez.
Une autre chose est que si vous rejoignez un nouveau vieux projet et que personne ne sait vraiment comment le code fait ce qu'il fait, alors vous ne pouvez pas déboguer en faisant écho à des variables/objets/... b/c vous n'avez aucune idée de ce qu'est le code exécuté du tout.
Dans mon travail, je suis confronté exactement à ce genre de situation et le XDebuging visuel m'aide à me faire une idée de ce qui se passe et où, du tout.
Meilleures salutations
Raffael
Le débogage dans un IDE est inestimable dans un environnement où les journaux d'erreurs et l'accès au shell ne sont pas disponibles, comme un hôte partagé. Dans ce cas, un IDE avec un le débogueur distant est le seul outil qui vous permet de faire des choses simples comme afficher stderr ou stdout.
Un débogueur peut se joindre à un processus en cours d'exécution
Souvent plus facile à déboguer du code fileté à partir d'un débogueur
Comme quelqu'un l'a dit ci-dessus: débogueur! = IDE.
gdb et (de retour dans la journée) TurboDebugger (autonome) fonctionnent très bien pour les langues qu'ils prennent en charge [ed], merci. (ou une technologie encore plus ancienne: le débogueur Clipper lié à l'exécutable xBase lui-même) - aucun d'entre eux ne nécessitait un IDE
De plus, bien que le codage C/++ soit plus rare, les instructions printf masquent parfois le bogue que vous essayez de trouver! (problèmes d'initialisation dans les variables automatiques sur la pile, par exemple, ou allocation/alignement de la mémoire)
Enfin, comme d'autres l'ont dit, vous pouvez utiliser les deux. Certains problèmes en temps réel nécessitent presque une impression, ou au moins un judicieux "* video_dbg = (is_good? '+': '-');" quelque part dans la mémoire vidéo. Mon âge montre, c'était sous DOS :-)
TMTOWTDI
En plus des nombreuses choses qui ont déjà été mentionnées, l'un des avantages les plus importants d'un débogueur par rapport à printf est que l'utilisation des instructions printf suppose que vous savez dans quelle fonction réside le bogue. Dans de nombreux cas, vous ne le faites pas, vous devez donc faire quelques suppositions et ajouter des instructions d'impression à de nombreuses autres fonctions afin de le localiser. Le bogue peut être dans le code du framework ou quelque part loin de l'endroit où vous pensez qu'il se trouve. Dans un débogueur, il est beaucoup plus facile de définir des points d'arrêt pour examiner l'état dans différentes zones du code et à différents moments.
En outre, un débogueur décent vous permettra d'effectuer le débogage de style printf en attachant des conditions et des actions aux points d'arrêt, de sorte que vous conserviez toujours les avantages du débogage printf, mais sans modifier le code.
Wauw, j'aime cette question. Je n'ai jamais osé le poser ...
Il semble que les gens aient simplement différentes façons de travailler. Pour moi, ce qui fonctionne le mieux, c'est:
- Avoir un modèle d'esprit solide de mon code, y compris la gestion de la mémoire
- Utiliser l'instrumentation (comme les déclarations imprimées) pour suivre ce qui se passe.
Je gagne ma vie depuis plus de 40 ans maintenant, travaillant dans des applications techniques et scientifiques non triviales en C++ et Python quotidiennement, et j'ai l'expérience personnelle qu'un débogueur n'aide pas moi un peu.
Je ne dis pas que c'est bon. Je ne dis pas que c'est mauvais. Je veux juste le partager.
Je voulais juste mentionner une fonctionnalité utile d'un débogueur de console vs printf et vs debugger dans un IDE.
Vous pouvez attacher à une application distante (évidemment, compilé en mode DEBUG) et inspecter son état en vidant la sortie du débogueur dans un fichier en utilisant l'utilitaire POSIX tee. Comparé à printf, vous pouvez choisir où sortir l'état en cours d'exécution.
Cela m'a beaucoup aidé lorsque je déboguais des applications Adobe Flash déployées dans un environnement agressif. Il vous suffit de définir certaines actions qui affichent l'état requis dans chaque point d'arrêt, démarrez le débogueur de console avec fdb | tee output.log, et parcourez quelques points d'arrêt. Après cela, vous pouvez imprimer le journal et analyser les informations par une comparaison approfondie de l'état dans différents points d'arrêt.
Malheureusement, cette fonctionnalité [journalisation dans un fichier] est rarement disponible dans les débogueurs GUI, ce qui permet aux développeurs de comparer l'état des objets dans leur tête.
Soit dit en passant, mon avis est qu'il faut planifier où et quoi déboguer avant de regarder un débogueur.
Un problème avec l'utilisation des instructions d'impression est qu'il gâche votre code. IE, vous avez une fonction avec 10 parties et vous savez qu'elle se bloque quelque part, mais vous ne savez pas où. Vous ajoutez donc 10 instructions d'impression supplémentaires pour localiser le bogue. Une fois que vous avez trouvé et résolu votre bogue, vous devez maintenant nettoyer en supprimant toutes ces instructions d'impression. Vous ferez peut-être ça. Vous oublierez peut-être et cela finira en production et la console de votre utilisateur sera pleine d'impressions de débogage.
Avec un IDE débogueur, vous pouvez voir les valeurs de TOUTES les variables dans la portée actuelle (tout en haut de la pile des appels) chaque fois que vous arrêtez l'exécution.
Les relevés imprimés peuvent être excellents, mais le fait de vider autant d'informations à l'écran à un endroit donné peut produire un lot entier de relevés imprimés.
En outre, de nombreux débogueurs IDE vous permettent de taper et d'évaluer des méthodes et d'évaluer des membres pendant que vous êtes arrêté, ce qui augmente encore la quantité d'instructions d'impression que vous auriez à faire.
Je pense cependant que les débogueurs sont meilleurs pour certaines langues que pour d'autres ...
Mon opinion générale est que IDE sont absolument incroyablement merveilleux pour les langages gérés comme Java ou C #, sont assez utiles pour C++ et ne sont pas très utiles pour langages de script comme Python (mais il se peut que je n'aie pas encore essayé un bon débogueur pour aucun langage de script)).
J'adore le débogueur dans IntelliJ IDEA quand je fais Java. J'utilise simplement des instructions d'impression lorsque j'utilise Python.).
Est-ce même une vraie question d'un vrai programmeur?
Quiconque a passé même 5 minutes à déboguer avec des instructions d'impression et à déboguer avec IDE - cela arrivera à lui sans même demander!