Les vrais programmeurs utilisent des débogueurs? [fermé]

Si des programmeurs expérimentés utilisent réellement des débogueurs, et si oui dans quelles circonstances. Bien que dans la réponse à cette question, j'ai dit «mois» il y a probablement des «années» - je n'utilise vraiment pas de débogueur. Donc, ma question spécifique est dans quelles circonstances utiliseriez-vous, en tant que programmeur expérimenté, un débogueur?

Je dirais que ne pas utiliser de débogueur est un signe d'inexpérience. Parcourir le code ligne par ligne est le meilleur moyen de suivre le flux d'exécution.

J'utilise souvent le débogueur, car je travaille sur un gros système et donc je crains. http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

Quelle que soit la longueur et la fréquence de lecture de votre code, il y aura toujours la possibilité qu'il contienne des bogues. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

L'erreur est humaine et on ne peut jamais prouver qu'un programme est correct, alors pourquoi ne pas utiliser des outils tels que le débogueur / test automatisé pour nous aider dans cette entreprise difficile?

Si le code est suffisamment court, des tests simples suffiront. De plus, s'il est court et que vous connaissez la nature du bogue, la lecture du code peut suffire. Cependant, une fois que la base de code est grande, implique plusieurs langues mélangées ensemble, plus 3 niveaux, alors vous devez simplement avoir une bonne couverture de test à plusieurs niveaux plus un très bon débogueur - sinon vous perdrez beaucoup de temps.

Alors, quand n'ai-je pas besoin d'un débogueur?

Je ne suis pas le codeur le plus intelligent, ni le plus expérimenté, mais quand même, je n'ai parfois pas besoin d'utiliser le débogueur. C'est quand:

• Le code est à moi ou bien écrit ET
• Il est écrit dans un langage lisible ET
• Le projet global est petit.

Quand dois-je compter fortement sur un débogueur?

• Réponse courte: souvent .
• Lorsqu'une application se bloque. Surtout quand il est déployé. L'installation de VS2010 sur cet ordinateur peut faire une différence entre "Erreur inconnue" et FileNotFoundException.
• Lorsqu'une bibliothèque tierce se bloque ou se comporte mal.
• Lorsque le code est mal écrit. Surtout si le même dossier a été touché par 10 personnes différentes au cours des 10 dernières années, dont 7 ne font plus partie de l'entreprise.
• Quand le projet est grand
• Quand le code est plutôt monolithique.
• Lorsqu'il y a plusieurs niveaux (GUI, SQL, BL) impliqués.

Notez que "débogueur" peut faire référence à plusieurs outils. J'utilise également le débogueur Visual Studio, le débogueur SQL (principalement pour les proc stockés) et le profileur SQL (pour déterminer quels SP sont appelés). Aurais-je besoin d'outils de ce calibre que j'écrivais un rapide script Python sysadmin-ish? Non. Si j'ai créé mon propre petit outil basé sur une interface graphique? Dépend. S'il s'agit de .Net WinForms - probablement pas. Si c'est WPF - oui.

Qu'est-ce qui définit un "vrai" programmeur de toute façon? Celui qui est rapide? bien informé? Est-ce bon en algorithmes? Écrit une bonne documentation? À quel moment exactement obtient-on son diplôme dans ce nouveau titre? Quand franchit-on la ligne magique?

Je dirais qu'un programmeur qui ne s'est pas sali les mains dans un effort de plus de 100 années-homme n'a pas eu la chance d'être humilié par la complexité et ses propres limites (ainsi que frustré par la qualité du code).

J'essaie personnellement d'utiliser le meilleur débogueur à ma disposition, et j'ai tendance à l'utiliser souvent. Si une tâche est assez simple et ne nécessite pas de débogueur - je ne l'utilise pas alors. Il ne faut pas trop de temps pour savoir si j'en ai besoin ou non.

...

Maintenant, en théorie, je pouvais lire la base de code pendant si longtemps, que je l'obtiendrais. Cependant, l'approche pratique fonctionne mieux, et je veux souvent réécrire ce code stupide que je vois. Malheureusement, il me faudrait plus de 10 ans pour nettoyer la base de code dans laquelle je me trouve. L'utilisation du débogueur est donc une première étape évidente. Ce n'est que lorsque je découvre que l'une des 5 millions de lignes de code agit, que j'analyse le fichier de haut en bas pour essayer de comprendre ce que fait cette classe.

"Je n'aime pas les débogueurs. Jamais, probablement jamais." - Linus Torvalds

En revanche, il n'a pas de compte Stack Overflow, donc je ne sais pas si vous êtes intéressé par son avis :)

Donc, ma question spécifique est dans quelles circonstances utiliseriez-vous, en tant que programmeur expérimenté, un débogueur?

• Lorsque vous ne parvenez pas à "déboguer" en lisant votre code.
• Lorsque vous ne parvenez pas à prédire les valeurs de certaines variables à un moment donné.
• Lorsque votre modèle mental de votre code ne correspond pas à la sortie donnée par votre code

Éditer:

J'ai eu la chance / le malheur de ne pas savoir comment utiliser un débogueur dans mon parcours de programmation. Ainsi, dans le passé, j'ai été obligé de déboguer sans débogueur. Cependant, après avoir appris à utiliser un débogueur -> je suis devenu 100 fois plus productif dans la recherche de bugs.

Pour donner une perspective légèrement différente des réponses actuelles; En tant qu'ingénieur logiciel embarqué travaillant sur des systèmes qui ont souvent un composant en temps réel, j'utilise rarement un débogueur.

À l'occasion, un débogueur peut être un outil incroyable et chaque fois que je suis capable de créer et d'exécuter du code sur un bureau, j'utilise toujours un débogueur.

Sur puce, avec des contraintes en temps réel, il y a alors une lourde charge associée à l'utilisation d'un débogueur. Dès que vous interrompez l'exécution, vous risquez de perturber, voire fatalement, le timing du reste du système. Généralement sur puce, printf dans le code non critique et les remous d'E / S dans le code critique sont le meilleur outil et le plus simple. Ce n'est pas aussi bon qu'un débogueur, mais c'est beaucoup moins cher de travailler avec un vrai système.

Je pense que les programmeurs expérimentés utilisent presque exclusivement des débogueurs, lorsqu'ils sont nécessaires. Quelle meilleure façon de retrouver un bogue que de suivre réellement l'exécution du code ...

Êtes-vous sous l'hypothèse que les Skeets du monde ne font pas d'erreurs ou ne savent tout simplement pas? Tous les programmes, sauf les plus triviaux, se comportent de manière inattendue dans certaines circonstances. Il va de soi que les problèmes devront être examinés. Ainsi, les choix sont d'utiliser des instructions d'impression, à une extrémité du spectre, ou de regarder examiner ce qui s'est passé, post mortem, de l'autre, ou de regarder au milieu pendant l'exécution du code et de comprendre ce qui se passe.

Une meilleure façon de penser est peut-être que les programmeurs expérimentés savent quand utiliser un débogueur. Dans le code avec peu de dépendances, regarder une trace de pile suffit probablement pour comprendre ce qui ne va pas. Mais il y a des scénarios compliqués où votre code fonctionne avec un autre code, et vous avez besoin d'un débogueur pour regarder les choses que vous n'avez pas écrites.

Non, et je programme depuis plus de 10 ans. Je le faisais quand je programmais en c / c ++. Maintenant je programme en java. La vérité est que si vous vous connectez correctement, vous vous retrouverez avec une trace de pile qui est suffisante pour la plupart des développeurs qualifiés. De plus, si vous écrivez de (bons) tests unitaires et des tests fonctionnels, cela élimine toute une classe de bogues.

On s'en fout? Ce que je veux savoir, c'est si l'utilisation d'un débogueur m'empêchera d'être un meilleur programmeur à long terme? Peut-être que les débogueurs étaient de moindre qualité lorsque de nombreux développeurs expérimentés ont commencé, ils étaient donc un obstacle. Est-ce une béquille qui empêche une compréhension plus profonde?

Un programmeur, probablement meilleur que le reste d'entre nous, a trouvé le besoin d'un débogueur et en a construit un (aucune idée de qui a créé le premier). Je suis sûr qu'ils ont été plus productifs grâce à cela. Je doute que la motivation ait été de permettre à des mortels mineurs d'écrire du code.

Rarement.

Vos méthodes doivent être suffisamment petites / simples pour être compilées et exécutées par votre esprit, les tests unitaires doivent couvrir les fonctionnalités. Si vous trouvez un bug, écrivez un test. Exécutez-le, réparez-le.

J'ai tendance à utiliser le débogueur uniquement lorsque ive a obtenu un comportement inattendu de code non testable, comme le framework ASP.NET.

Dans Smalltalk, je développe presque entièrement dans le débogueur:

1. Écrivez un test qui, je le sais, échouera.
2. Exécutez le test. En cas d'échec, le débogueur s'affiche.
3. Écrivez, dans le débogueur, le code nécessaire pour réussir le test.
4. Reprenez l'exécution.
5. Si je reçois un feu vert, passez à l'étape 1 avec un nouveau test d'échec. Sinon, dans le débogueur, découvrez ce que j'ai fait de mal et corrigez-le.

J'utilise un débogueur quand j'en ai besoin. Ce n'est pas quotidien, mais cela se produit occasionnellement. Il est parfois préférable de parcourir le code pour voir ce qui se passe exactement.

Je dois admettre que j'utilise de moins en moins de débogueurs. Je développe en Delphi depuis plus de 10 ans. J'écris également des procédures stockées en PL / SQL. Depuis quelques mois, je suis aussi développeur PHP.

J'utilise principalement le débogueur dans l'un ou l'autre de ces cas si je trouve un morceau de code obscur qui a été écrit il y a des années et que je dois le modifier. Il est parfois utile de découvrir le fonctionnement exact d'un programme s'il est difficile de lire le code. En PHP, ce n'est presque jamais nécessaire, mais en Delphi, qui est basé sur des événements, cela aide parfois lorsque vous avez un framework complexe.

Mais comme vous le dites, l'utilisation du débogueur est une exception. La plupart des problèmes sont résolus en lisant simplement le code et en corrigeant les erreurs que vous (ou quelqu'un d'autre) avez faites.

Mais cela vaut pour parcourir le code. J'utilise assez souvent la pile d'appels lorsqu'une exception se produit, et je mets parfois un point d'arrêt quelque part pour inspecter une variable. Mais presque toujours dans un morceau de code qui a quand même besoin d'une refactorisation approfondie.

Je code occasionnellement sans débogueur, mais uniquement lorsqu'il est forcé de le pointer, c'est-à-dire. gunge intégré hérité sur un 8051 ou Z80.

À mon humble avis, vous avez besoin d'un débogueur et de vous connecter à tout travail complexe. Une fois ne remplace pas l'autre. Un système de journalisation ne peut pas aider si l'application se trouve dans un pilote, par exemple, où la seule chose que le code peut faire est d'interagir avec le matériel et de définir un sémaphore.

Un débogueur ne peut pas résoudre une erreur système lorsque les applications fonctionnent correctement selon la façon dont vous les avez écrites, mais le système ne fonctionne toujours pas en raison d'une erreur de protocole de communication intermittente.

Donc, j'ai besoin du débogueur pour supprimer les bogues stupides et flagrants et les problèmes matériels. J'ai besoin d'une bonne journalisation pour détecter les bogues d'intégration système intermittents.

Je dois avoir les deux - j'ai besoin de toute l'aide que je peux obtenir!

J'utilise uniquement un débogueur lorsque ces étapes échouent:

1. Obtenez l'erreur reproductible. Pense. C'est souvent tout ce qui est nécessaire.
2. Vérifiez toute trace de pile et journaux.
3. Ajoutez plus de journalisation autour du code incriminé.

Ces étapes prennent en charge 95% de tous les cas. Cela signifie que j'utilise rarement un débogueur, et quand je le fais, il a tendance à me donner trop d'informations et je m'embourbe dans des détails non liés. Cela est particulièrement vrai si vous travaillez sur un système multithread en temps réel.

Des déclarations de journalisation judicieusement placées vont donc loin.

Serait-ce simplement que les programmeurs très expérimentés sont les mêmes que les très vieux programmeurs, et ils ont appris à programmer et ont formé leurs habitudes, à l'époque où les débogueurs n'étaient pas toujours disponibles, et parfois pas très bons?

Si vous êtes vraiment bon au débogage printf (et dans les années 80, nous n'avions pas beaucoup d'autre choix que de devenir vraiment bon), peut-être qu'un débogueur n'ajoute pas grand-chose.

C'est une question de choix personnel.

Honnêtement, je pense que les débogueurs sont utiles dans certaines situations où cela aide beaucoup de savoir ce qui se passe sur votre RAM à une étape donnée de l'exécution de votre programme.

L'utilité principale d'un débogueur est d'arrêter un programme sans que le programme soit conçu pour s'arrêter lui-même: cette fonctionnalité est très importante.

En dehors de ces 2 fonctionnalités, je ne pense pas qu'un débogueur soit vraiment nécessaire; tout programme complexe que vous faites devrait avoir une sorte de mode "verbeux", c'est-à-dire dire tout ce qu'il fait avec printf ou std :: cout, quels choix il a fait et beaucoup d'autres paramètres.

Imaginez simplement que vous créez un programme et que l'utilisateur a un problème à l'utiliser: comment savoir s'il l'utilise de la façon dont il a été conçu pour être utilisé, ou si la chose dont il se plaint pourrait être un bug?

Les débogueurs sont comme la direction électrique de votre voiture: il est plus confortable d'en avoir une, mais cela n'améliorera pas votre conduite.

La programmation est une question de conception et de logique, la façon dont les outils peuvent vous aider à suivre des trucs ne fait pas de vous un meilleur programmeur.

De plus, les débogueurs sont utiles pour les langages compilés, et encore moins pour les langages interprétés.