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

101

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 "?

jonathan
la source
19
Bonjour Jonathan, j'ai révisé votre question pour éviter les pièges d'un coup de gueule et garder la question ouverte: je pense - telle que libellée maintenant - que c'est une question assez décente, qui peut être répondue.
Exemple: considérons un code a = 6/3., À la place des fautes de frappe que vous avez saisies a = 6/2. Maintenant, vous effectuez une recherche au niveau mnémonique., Les instructions ADD, JMP, puis vous trouvez qu’il y avait une itération supplémentaire au lieu de 2. Ensuite, vous réalisez que le mauvaise faute de frappe. Vous pouvez maintenant en déduire à quel point il est ridicule de toujours utiliser un débogueur.
EAGER_STUDENT

Réponses:

153

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.

dasblinkenlight
la source
27
+1 Je trouve que "programmer en devinant" est une phrase chargée. Il n'y a pas de substitut à la pensée. Ce que le PO n’explique pas, c’est l’efficacité de la "devinette". Mon doute est que c'est purement deviner (c.-à-d. Approche spaghetti sur le mur), mais plutôt en utilisant un raisonnement déductif Les débogueurs ont leur place, mais ils ne sont pas une panacée pour le raisonnement déductif et la compréhension du code.
Bill le
8
@DJClayworth Ce n'est pas tout à fait exact: parfois, essayer d'utiliser un débogueur est un mauvais choix, même si vous avez un bon débogueur à votre disposition: vous finissez par perdre beaucoup de temps sans accomplir beaucoup. Un cas qui me vient immédiatement à l’esprit est la résolution de problèmes de concurrence; les autres sont en train de déboguer des algorithmes récursifs avec des facteurs de branchement élevés, certains algorithmes de programmation dynamique et des routines de service d'interruption matérielle. Bien sûr, il est idiot de ne pas utiliser de débogueur lorsque vous en avez réellement besoin, mais décider quand vous commencez à avoir besoin d’un débogueur est un choix hautement individuel.
dasblinkenlight
9
+1 Bien que je trouve un débogueur précieux pour certains types de bogues (en particulier dans les algorithmes plus complexes), rien ne peut remplacer une simple compréhension du code
Chris Browne
7
@DJClayworth J'ai délibérément opté pour une déclaration plus forte que "quelques occasions où il n'est pas préférable d'utiliser un débogueur": ma brève rencontre avec une programmation compétitive m'a appris qu'instinctivement, rechercher un débogueur n'est pas le comportement le plus efficace pour moi . Ces jours-ci, je commence par (1) relire rapidement le code et (2) en examinant la trace de débogage (si disponible) avant (3) de chercher un débogueur. Dans de nombreux cas, la troisième étape est inutile, car je repère le problème aux étapes (1) ou (2), écris un test unitaire qui reproduit le problème et code un correctif, le tout sans utiliser de débogueur.
dasblinkenlight
10
Je pense que ce que vous voulez vraiment dire, c'est qu'un programmeur devrait avoir une séquence de débogage , au lieu de cliquer sur le bouton magique "trouver un bug". Un débogueur est un outil extrêmement puissant, mais vous n’utilisez pas la tronçonneuse pour couper les haies.
Spencer Rathbun
41

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).

Programmateur
la source
35

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"

JohnFx
la source
12
Je ne suis pas d'accord, mais je ne vais pas voter. Comme le dit Delnan, si vous pouvez comprendre ce que fait le code, il peut être plus rapide de repérer ce qu’il fait de mal que de parcourir le débogueur et d’essayer de le localiser. Cela dit, un développeur qui refuse d'utiliser un débogueur lorsqu'il ne parvient pas à identifier le problème en lisant le code commet une grave erreur.
@Mark plus le bonus supplémentaire de mal diagnostiquer le problème et de brancher un nouveau défaut.
Keith apporte le
11
@ Mark Bannister - Je vois ce que vous dites. Permettez-moi de modifier cela en, si vous recherchez le problème dans le code depuis plus de 15 minutes, abandonnez et utilisez le débogueur sans être obstiné.
JohnFx
9
Je pense qu'un bon programmeur ne devrait pas dépendre du débogueur. Cela ne devrait pas l'empêcher d'utiliser un immédiatement ( le cas échéant), une fois que sa perspicacité ne - ou périodiquement, pour vous assurer que sa perspicacité est toujours sur la bonne voie ...
comingstorm
1
@mark sauf si vous travaillez sur une très petite base de code, je pense qu'il est impossible de comprendre chaque ligne de code. 95% de mes bogues actuels sont résolus de la manière que vous décrivez, mais les plus difficiles sont ceux où vous avez besoin du débogueur.
wobbily_col
31

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.

jqa
la source
18
+1 "La plupart des bugs sont causés par des suppositions" sont des mots très sages
ZJR
15
Je suppose que tous les bugs sont causés par des hypothèses. (Voir ce que j'ai fait là-bas? = P)
dan_waterworth
4
@ZJR: C'est pourquoi assertc'est si génial. Vérifiez vos hypothèses. Vérifiez-les souvent.
Zan Lynx
@ dan_waterworth: Ce n'est pas vrai. D'une part, cela pourrait être une faute de frappe.
Thomas Eding
13

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.
DJClayworth
la source
2
Bien que je sois d’accord avec vous sur la plupart de vos messages, j’estime qu’un incompétent est injuste. Il est possible de développer sans l'utilisation d'un débogueur, c'est tout simplement inefficace. Certaines personnes découvrent les débogueurs avant les autres!
ChrisFletcher
Je ne jetterais pas avec désinvolture des mots comme "incompétent". Je connais quelqu'un qui débogue entièrement avec les déclarations imprimées, et personne d'autre n'approche de faire la contribution qu'il fait.
Mike Dunlavey le
2
@ MikeDunlavey Cette personne sait-elle utiliser un débogueur et choisit de ne pas l'utiliser? Bien. S'ils ne le savent pas, je maintiens ma déclaration.
DJClayworth
2
Tenez-vous comme vous le souhaitez, un moment pourrait facilement venir où cet adjectif pourrait être appliqué à vous. Ensuite, vous comprendrez - ce sont des trucs de cour d'école.
Mike Dunlavey
9

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.

FrustratedWithFormsDesigner
la source
8

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é.

Jeff Grover
la source
+1 Il est souvent plus rapide d'ajouter une instruction print et de relancer le test, puis d'utiliser un débogueur.
Winston Ewert le
@ winston - il est souvent plus rapide de lancer le débogueur que d'écrire plusieurs instructions d'impression jusqu'à ce que vous trouviez l'emplacement du code problématique. Tout dépend. Comme vous le décrivez, les problèmes simples sont généralement résolus plus rapidement, mais le débogueur nécessite des problèmes complexes. Être capable d'utiliser les deux est mieux que de s'en tenir strictement à un principe absolu.
wobbily_col
7

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.

thSoft
la source
6

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).

Kevin Hsu
la source
5

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).
TrueLifeCoder
la source
2
+1 pour évoquer le problème du débogage dans des environnements concurrents, où l'utilité des débogueurs traditionnels diminue souvent à près de zéro.
dasblinkenlight
4

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.

pcalcao
la source
4

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.

utilisateur977645
la source
4

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.

polemon
la source
4

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.

Jim McKeeth
la source
4

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.

bchetty
la source
3

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.

Ccoakley
la source
3

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.

BЈовић
la source
2

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.

Christian P
la source
2

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.

anon
la source
0

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.

Yarony
la source
-1

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.

H Greene
la source
2
Cet homme de paille ne répond pas à la question posée, il n'y a nulle part une déclaration "Les vrais programmeurs n'ont pas besoin de débogueurs"
gnat