Quel est l'avantage d'éviter l'utilisation d'un débogueur?

Au cours de ma carrière, j'ai remarqué que certains développeurs n'utilisaient pas d'outils de débogage, mais vérifiaient de manière ponctuelle le code erroné pour déterminer le problème.

Bien qu'il soit souvent utile de trouver rapidement des erreurs dans le code sans un débogueur, il semble moins productif de passer beaucoup de temps à rechercher les problèmes lorsqu'un débogueur trouverait facilement de petites erreurs comme des fautes de frappe.

Est-il possible de gérer un complexe sans débogueur? Est-ce conseillé? Quels avantages y a-t-il à utiliser le " débogage psychique "?

Ce qui ressemble à des devinettes de l'extérieur s'avère souvent être ce que j'appelle le "débogage dans votre esprit". D'une certaine manière, cela ressemble à la capacité des grands maîtres à jouer aux échecs sans regarder un échiquier.

C’est de loin la technique de débogage la plus efficace que je connaisse, car elle ne nécessite pas de débogueur. Votre cerveau explore plusieurs chemins de code en même temps, ce qui permet un meilleur traitement que celui que vous pouvez obtenir avec un débogueur.

Je n’étais pas conscient de cette technique avant d’entrer brièvement dans le monde de la programmation compétitive , où utiliser un débogueur signifiait perdre de précieuses secondes. Après environ un an de compétition, j’ai commencé à utiliser cette technique presque exclusivement comme première ligne de défense, suivie de la journalisation du débogage, avec l’utilisation d’un débogueur réel assis à la troisième place. Un effet secondaire utile de cette pratique est que j'ai commencé à ajouter de nouveaux bogues à un rythme plus lent, car le "débogage dans mon esprit" ne s'est pas arrêté lorsque j'ai écrit le nouveau code.

Bien sûr, cette méthode a ses limites, principalement en raison de la capacité de son esprit à visualiser plusieurs chemins dans le code. J'ai appris à respecter ces limites de mon esprit en me tournant vers un débogueur pour corriger des bogues dans des algorithmes plus avancés.

Plus je connais une base de code, moins j'ai besoin d'un débogueur (mais je vérifierais quand même l'erreur rapportée, c'est un indice important dans tout raisonnement).

C’est un bon outil pour comprendre un comportement dynamique de complexité petite à moyenne, mais j’apprends souvent qu’il m’attache davantage aux détails qu’au détail. Et au bout d’un moment, c’est là que se posent les problèmes: dans des interactions plus larges, dont le comportement dynamique a tendance à être plus facilement compréhensible avec d’autres outils (enregistrement des entrées et des sorties aux limites du module, par exemple).

Ce ne sont peut-être pas de mauvais programmeurs, mais ce sont probablement des dépanneurs terriblement inefficaces.

J'ai tendance à suivre les conseils de Debugging: Les 9 règles indispensables pour trouver même les problèmes de logiciels et de matériel les plus insaisissables (David Agans), et celui-ci relève carrément de "Arrêter de penser et de regarder"

Tout travail nécessite d'utiliser les bons outils de la bonne manière. Si vous avez un débogueur, utilisez-le pour voir ce qui se passe réellement. La plupart des bugs sont causés par des hypothèses.

J'ai travaillé avec des développeurs qui refusent d'utiliser des débogueurs parce qu'ils le savaient mieux. La réponse classique que j'ai eue une fois était «le crash ne venait pas de moi, j'ai passé toute la journée à inspecter le code [là où il se bloquait] et rien ne se passait». (Qu'en est-il de cette valeur nulle lue dans la base de données?) Le patron semblait penser que c'était une excellente réponse, mais le client ne le pensait pas.

Je suis sorti de cette équipe aussi vite que j'ai pu. Leur but était de créer un problème simple de 10 minutes en un problème occupé toute la journée.

Votre meilleur guide pour la pratique du débogage est le livre Code Complete de Steve McConnel . Le chapitre 23 traite en détail du débogage, et je vais en distiller quelques points.

1. Comprendre le problème est important et l’utilisation du débogueur n’est pas un substitut.
2. Deviner est une mauvaise approche pour le débogage. Si vos collègues ont vraiment recours à la conjecture qu'au lieu de penser au problème, ils font du mauvais travail. Guesswork signifie coller des instructions d'impression aléatoires dans le code et espérer trouver quelque chose d'utile.
3. Si vos collègues ne savent vraiment pas comment utiliser un débogueur (plutôt que de choisir de ne pas en utiliser un), alors oui, ils sont incompétents, tout comme quelqu'un qui ne connaît pas la syntaxe du langage qu'ils sont censés utiliser.

Dur à dire. Le débogage par devinettes pourrait fonctionner si vous avez déjà une idée de ce qu'est le bogue (valeur incorrecte transmise à une fonction de bibliothèque, éventuellement SQL non valide, etc.). J'admets que je le fais parfois lorsque l'erreur elle-même semble petite ou évidente, telle que "tampon de caractères trop petit" - la trace de pile me montre la ligne où elle a échoué et je n'ai pas besoin d'un débogueur pour la résoudre.

Faire tout ce temps peut être contre-productif et si les quelques "suppositions" échouent, deviner est probablement la mauvaise stratégie de résolution de problèmes et un vrai débogueur devrait être appelé. Normalement, je dirais qu'il n'y a absolument rien de mal à utiliser le débogueur .

Cela étant dit, j'ai travaillé avec des outils et des environnements dans lesquels le débogueur était si difficile à faire fonctionner correctement, ou si minime et inutile que deviner était malheureusement souvent une meilleure approche. J'ai travaillé avec des outils propriétaires qui n'avaient même pas les débogueurs appropriés. Je suppose qu'il est possible que si une personne travaille trop longtemps dans de tels environnements, elle finit par perdre sa confiance en les débogueurs et à ne compter que sur l'approche de devinette.

Je suis surpris que la discussion sur ce sujet n'ait pas parlé de "tests unitaires".

Parce que je développe des tests, je ne passe pas beaucoup de temps dans le débogueur. Il y a 10 ans, je parcourais consciencieusement le débogueur:

1. Après avoir écrit un morceau de code pour s’assurer qu’il fonctionne et
2. Quand j'ai reçu un rapport de bogue pour essayer de diagnostiquer le problème

Ce que j'ai découvert après 10 ans de développement piloté par les tests, c'est que je suis beaucoup plus productif en tant que programmeur si:

1. J'écris des tests unitaires avant d' écrire le code pour m'assurer que je l'ai bien écrit
2. J'écris des tests unitaires immédiatement après la réception d'un rapport de bogue pour tenter de dupliquer et d'explorer le problème.

Permettre à l'ordinateur de parcourir le code et de valider le résultat est des milliers de fois plus rapide que je ne peux le penser ou de parcourir le code pour valider mentalement les résultats, sans commettre d'erreur.

Je dois encore passer occasionnellement au débogueur, et je suis toujours en train d'analyser mentalement le code ... mais rarement, surtout pour un code très compliqué.

Personnellement, j'essaie de minimiser l'utilisation d'un débogueur en:

• en utilisant des vérificateurs statiques et des options de compilation similaires qui suggèrent des sources possibles de bogues simplement en analysant le code
• écrire du code avec le moins d'effets secondaires possible, dans le style le plus fonctionnel possible, en éliminant si possible l'état mutable
• écrire des tests unitaires avec la granularité raisonnable minimale
• ne pas avaler les exceptions

Bien sûr, tout le monde fait des erreurs, donc même en composant des programmes de cette façon, si un test échoue, j'utilise le débogueur pour inspecter la valeur d'une expression intermédiaire. Mais en adhérant aux principes ci-dessus, le défaut est plus facile à localiser et le débogage ne signifie pas un processus indéterministe douloureux.

Utilisez le débogueur autant que possible. Le débogueur résoudra simplement le problème (regardez, nous n'avons pas vérifié cette valeur), ou fournira beaucoup de contexte utile pour analyser le code pertinent (wow, la pile est totalement foirée, je vais soit un problème de débordement de mémoire tampon).

Le débogage est un outil très utile pour inspecter l'état des objets et des variables dans votre code au moment de l'exécution.

Comme mentionné précédemment dans les réponses ci-dessus, le débogage est extrêmement utile, mais dans certains cas, il est limité.

D'après mon expérience, utiliser le débogueur est très utile car il permet de révéler de fausses hypothèses sur l'état de mon code. Certaines personnes ne sont pas aussi habiles à lire le code pour trouver un bogue, aussi le débogage peut-il aider à révéler de fausses hypothèses que vous ou un autre développeur avez faites sur l'état du code.

Vous vous attendez peut-être à ce qu'un paramètre ne soit jamais nul lorsqu'il est passé à une méthode. Vous ne devez donc jamais vérifier ce cas et poursuivre dans la méthode comme si ce paramètre ne serait jamais nul. La réalité est que ce paramètre finira par être null à un moment donné, même si vous définissez comme pré-condition à la méthode que le paramètre ne doit jamais être null. Cela arrivera toujours.

Contrairement à l'utilité des débogueurs dans les exemples mentionnés ci-dessus, je trouve qu'il est difficile et plutôt inutile d'utiliser lorsque plusieurs processus sont impliqués (multi-threading (c'est-à-dire, concurrence, traitement asynchrone)). Cela peut aider, mais il est facile de perdre votre orientation dans le brouillard multithread lorsque les points d'arrêt du débogueur sont atteints dans un thread au point A et un thread complètement séparé au point B. Le développeur est obligé de pousser le nouveau point d'arrêt " processus de pensée "sur le dessus de la" pile "de son cerveau et s'orienter vers le code à la pointe du nouveau point d'arrêt. Lorsque la pertinence du point d'arrêt B diminue, le développeur revient au premier point d'arrêt et doit rappeler ce qu'il recherchait avant le déclenchement du point d'arrêt B. Je sais que cela peut prêter à confusion,

De plus, l'imprévisibilité du code concurrent peut distraire davantage le développeur lors du débogage du code concurrent.

En conclusion, à mon avis honnête:

• Débogage lorsque la simultanéité est utilisée = tendance accrue à perdre le focus du "modèle de pensée de débogage"

et

• anytime else = productivité de débogage accrue, votre attention n'est pas interrompue par des points d'arrêt imprévus (inattendus en raison des conditions de concurrence).

Je pense qu'ils sont un peu trop hardcore. Personnellement, lorsque je rencontre un bogue, je revérifie le code et essaie de le tracer dans ma tête à partir de la logique du programme, car cela me permet parfois de découvrir d'autres problèmes ou effets secondaires plus facilement que d'utiliser simplement le débogueur et de corriger le bogue où il se manifeste. .

Même quand je pense que je l'ai cloué, je le débogue habituellement pour m'assurer que j'ai raison. Lorsque le problème est un peu plus complexe, je pense que le débogage est absolument essentiel.

Aussi ... juste mon avis mais, il n'y a aucune excuse pour ne pas prendre un avantage décent des outils qu'un IDE moderne peut apporter à la table. Si cela vous aide à terminer votre travail plus rapidement et de manière plus fiable, vous devriez l'utiliser.

Je déteste généraliser, mais beaucoup de programmeurs que j'ai rencontrés pensent qu'il n'y a qu'un seul moyen de résoudre un problème (leur manière). Il est facile de supposer que tous les tests possibles ont été pensés. Une perspective différente peut être très utile.

La programmation par essais et erreurs peut donner lieu à de très bonnes nouvelles approches, et attraper des choses que d'autres ont manquées.

L'inconvénient prend généralement beaucoup plus de temps.

Euh, ça dépend de la personne. Personnellement, je n’utilise pas beaucoup de débogueurs moi-même. Lorsque je programme des micro-contrôleurs, j'utilise essentiellement des voyants ou l'écriture de données sur des EEPROM pour "déboguer" le code qui s'y trouve. Je n'utilise pas JTAG.

Lorsque je programme des logiciels pour PC ou serveurs, j'ai tendance à utiliser la journalisation et de nombreuses sorties de console. Pour les langages de style C, j'utilise les directives du préprocesseur et, en Java, les niveaux de journalisation.

Puisque je n'utilise pas de débogueurs, diriez-vous que je fais quelque chose de mal? Ce sont les travaux des éditeurs, pour me montrer où j’ai des erreurs syntaxiques, et quand il ya une erreur logique, je dois juste exécuter des tests.

Il y a une différence entre ne pas avoir besoin d'utiliser un débogueur et ne pas savoir comment (ou refuser de) utiliser un débogueur. Le débogueur n'est que l'un des nombreux outils à utiliser pour le suivi et la correction des bogues. J'ai travaillé avec des développeurs qui peuvent le comprendre et d'autres qui pensent le pouvoir.

La meilleure combinaison consiste à écrire votre code afin qu'il soit facile à tester via des tests unitaires et enregistre les erreurs. Ensuite, vous espérez que vous n’avez pas besoin de consulter les journaux ni d’utiliser le débogueur. C'est un peu comme acheter une assurance. Si tout va bien, vous n’avez jamais besoin de l’utiliser, mais une fois que vous rencontrez un bogue qui ne peut pas être résolu en revérifiant le code, il est trop tard pour ajouter une gestion / journalisation des erreurs appropriée, des tests unitaires ou apprendre à utiliser un débogueur.

Différents outils / plates-formes favorisent différentes techniques de débogage (débogueur, journalisation, tests unitaires, etc.) Tant que les développeurs connaissent quelques-unes des techniques de leur plate-forme / outil, en plus de la simple vérification du code, ils peuvent développeur expérimenté, mais s’ils n’ont qu’une astuce en matière de débogage, ils rencontreront un bogue qu’ils ne pourront ni trouver ni résoudre.

Beaucoup de réponses, mais pas une mention à propos de Heisenbug ?!?!

Heisenbugs se produit parce que les tentatives courantes de débogage d'un programme, telles que l'insertion d'instructions de sortie ou son exécution dans un débogueur, modifient généralement le code, modifient les adresses mémoire des variables et le moment de son exécution.

J'utilise le débogueur, seulement dans le pire des cas (pour les bogues difficiles à trouver). En outre, conformément aux meilleures pratiques évoquées par de nombreux développeurs / testeurs de renom, il est bon de tester le code de manière approfondie. De cette façon, vous pouvez couvrir la plupart des problèmes et par conséquent, il ne serait pas nécessaire d'utiliser le débogueur.

J'ai lu un argument contre le débogage du débogueur ici récemment (ou était-ce StackOverflow?). Vous devriez avoir des cas de test contre votre code. Si vos tests réussissent, votre débogage ne va probablement pas exercer le bogue (hypothèse: vous déboguez avec des données similaires à vos données de test).

En revanche, la journalisation est obligatoire. Si vous réussissez vos tests et que vous vous déployez en production, vous constaterez peut-être un bogue. La preuve du bogue provient de quelque chose qui s'est passé dans le passé. c'est-à-dire que quelqu'un dit: "Comment cela s'est-il trouvé là?" Si vous n'avez pas de bons journaux, vous ne trouverez jamais la cause. Même un débogueur peut ne pas être utile à ce stade, car vous ne savez pas à quoi ressemblent les données qui a réellement provoqué le bogue. Vous devez être en mesure de déboguer l'application à partir des journaux.

Malheureusement, je paraphrase pas mal, et rend peut-être l'argument initial un mauvais service. En particulier, la position "Il existe d'importants outils d'aide au débogage pour passer du temps à développer" pourrait être orthogonale à l'importance des débogueurs. Mais la partie concernant la difficulté de définir l’état du système dans une configuration qui rend le débogage utile pour rechercher des bogues m’a paru être une réflexion.

Avec de bons tests unitaires et des exceptions qui vous fournissent la trace, vous devez rarement utiliser un débogueur.

La dernière fois que j'ai utilisé un débogage, c’était quand j’ai récupéré un fichier core dans une application existante.

Suis-je un "sbire debbuger" ou ces mecs sont-ils "trop ​​hardcore"?

Ni. Ce sont juste des types de personnes qui aiment rendre leur vie plus dure qu’elle ne le devrait.

Le débogage est juste un outil qu'un bon développeur devrait utiliser avec compétence.

Certes, vous pouvez parfois savoir par cœur où le bogue peut être si vous connaissez la base de code. Mais vous pouvez également perdre une journée ou une semaine entière pour trouver un bug embêtant simplement en regardant dans le code.

Dans les langages à typage dynamique sans débogage (même s'il s'agit simplement de transférer des valeurs sur la console), il est parfois impossible de deviner.

Donc, pour répondre à votre question, ce sont peut-être de brillants programmeurs, mais leurs compétences en matière de dépannage et leur maîtrise de la recherche de bogues sont mauvaises.

Dépend de la portée d'un problème. Si le programme est petit et que les choses sont bien divisées, vous pouvez probablement le découvrir en regardant. Si le programme comprend 4,5 millions de lignes de code développées par une équipe de plus de 100 personnes au cours de plusieurs années, il sera impossible de détecter certains bugs.

Celui en question dans ledit programme (en C) était un écrasement de la mémoire. Le débogueur avec un point d'arrêt de la mémoire a identifié la ligne de code incriminée dès l'apparition du bogue. Mais dans ce cas, il n’ya aucune chance que quelqu'un ait lu et conservé les 4,5 millions de lignes de code identifiant le seul endroit écrit par quelqu'un au-delà de son tableau (il aurait également dû connaître la disposition d'exécution de la mémoire à l'exécution pour le programme gargantuan). environ 10 minutes dans une longue série d’entrées pour l’atteindre).

Le point important: dans les petits programmes ou les choses hautement modulaires, vous pouvez vous échapper sans un débogueur. Si le programme est vraiment volumineux et complexe, le débogueur peut vous faire gagner beaucoup de temps. Comme d’autres l’ont dit, c’est un outil qui présente des situations qui surpassent toutes les autres méthodes et d’autres où ce n’est pas le meilleur choix.

Si le bogue survient sur l'ordinateur d'un client ou sur un ordinateur dont l'environnement est très différent du vôtre, la configuration d'un débogueur / débogueur distant est fastidieuse. Donc, pour le jour froid où vous avez un bogue sur le terrain, la réponse "mais ... je n'ai pas de débogueur" n'aide pas. Par conséquent, vous devez développer un ensemble de compétences de dépannage et de recherche du bogue simplement en comprenant le code et les fichiers journaux.

Quel tas de bêtises: "Les vrais programmeurs n'ont pas besoin de débogueurs." Autant dire qu'un vrai programmeur n'a besoin d'aucun IDE, donnez-moi juste un bloc-notes et un crayon terne. Le débogueur est un outil comme un autre qui contribue à la productivité.

En outre, considérez que toutes les personnes chargées du débogage du code ne sont pas familiarisées avec ce code en question. Beaucoup d'entrepreneurs de temps à venir viennent dans un environnement où ils n'ont qu'un idéal général, ce qui se passe. Ils peuvent même recevoir une description détaillée d’un environnement - ou une carte de schéma datant de 20 ans et un guide sur les conventions de nommage arcaniques (essayez de comprendre la différence entre la table X1234 et la table X4312 avec les champs F1, F2 et F3 [oui, un déchet de ce genre] existe] lorsque vous êtes nouveau), mais cette description est souvent fausse; sinon, pourquoi y a-t-il une erreur "mystère"?

En tant que débutant dans un environnement, vous pouvez passer des heures ou des jours à cartographier et à apprendre à "connaître" une base de données volumineuse pour résoudre un problème que vous pourrez peut-être résoudre sans avoir à consulter à nouveau. C'est une énorme perte de temps et d'argent. Si vous avez accès au débogueur, vous regardez ce qui se passe, corrigez-le et vous êtes parti en quelques minutes. Tout cela "vous n'avez pas besoin de débogueurs" hooey est juste une bouffotte élitiste.