Comment passer moins de temps sur le débogage? [fermé]

Suivant la règle de Pareto, un programmeur ne consacre que 20% de son temps à des choses vraiment utiles.

Je passe 80% de mon temps à déboguer, à réparer de petites choses pour que tout fonctionne.

Existe-t-il un moyen de passer moins de temps à déboguer?

Code en Agda ou Coq . Une fois votre code compilé, cela fonctionnera. Si c'est trop hardcore, choisissez une langue avec un système de type plus faible, par exemple, Haskell ou F #.

Mais dans la plupart des cas, vous serez beaucoup plus productif en consacrant 20% de votre temps au codage et 80% aux tests et au débogage. 100% d'une semaine, c'est beaucoup plus que 20% d'une heure. Si le débogage est ce dont vous avez besoin pour faire avancer les choses, le débogage n'est pas une perte de temps et vous ne devriez pas vous soucier "d'améliorer" cette proportion.

Tests unitaires.

Après avoir commencé à appliquer les tests unitaires, j'ai constaté que le code que j'avais écrit était mieux structuré. Il était alors plus facile d'éviter et de repérer les bogues. J'ai passé moins de temps à déboguer, mais plus de temps à écrire le test unitaire.

Je pense également que le temps investi dans les tests unitaires a un meilleur retour sur investissement que le débogage. Après une session de débogage, je viens de corriger le code. Le même bug peut apparaître des semaines plus tard et je dois déboguer à nouveau. Si j'écris un test unitaire, le bogue est documenté comme un test unitaire et agit plus tard comme un test de régression. Si le bug réapparaît, les tests unitaires me le révèlent.

• Tests unitaires, afin de savoir si votre code fonctionne en premier lieu.
• Au moins une certaine quantité de conception initiale, afin que vous sachiez ce que vous codez.
• Revues de code, car deux têtes valent mieux qu'une et quatre yeux valent mieux que deux. Sans oublier que même essayer d'expliquer votre code à quelqu'un d'autre révèle de nombreux problèmes.
• Contrôle de version, afin d'isoler rapidement les modifications qui ont pu causer le bogue.
• Refactoring, afin que votre code ne se transforme pas en un horrible gâchis incompréhensible.
• Lisez "Clean Code" de Robert C. Martin et faites ce qu'il vous dit. Vous serez étonné par les résultats.

Les tests unitaires aideront, espérons-le, si vous introduisez des bogues, ils se briseront avant votre code de production - des tests unitaires bien écrits vous diront également exactement ce qui s'est cassé.

Cela vous obtiendra la plupart du temps, mais pour 99,999% des projets, vous devrez toujours déboguer les choses de temps à autre. La meilleure chose à faire ici que je trouve est de faire 4 choses:

1. utilisez des types immuables dans la mesure du possible - si quelque chose a une mauvaise valeur, vous saurez exactement où chercher immédiatement (où il est en cours de construction).
2. appliquer des invariants dans le code - si vous savez qu'une valeur n'est certainement pas autorisée, vérifiez-la et lancez une exception dans les points d'entrée aux méthodes et aux constructeurs. Si vous combinez cela avec des types immuables, vous pouvez également commencer à faire certaines hypothèses sur ce qui est valide ou non.
3. assurez-vous d'avoir une journalisation adéquate - obtenez-la tôt et cela vous donnera beaucoup d'informations importantes sur les problèmes. AOP fonctionne vraiment bien ici. La journalisation après coup est généralement un peu délabrée - obtenez-la tôt dans le cadre de la configuration du projet.
4. si votre base de code est suffisamment grande / complexe, évitez d'utiliser des primitives - par exemple, utilisez un type appelé 'Age' plutôt que d'utiliser simplement un int. Cela semblera un peu inutile au début, mais être capable de retrouver toutes les utilisations de quelque chose en un instant est une énorme victoire de débogage.

Mon 80% est le débogage. Je corrige des bugs simples et essaye de faire fonctionner tout ça.

Commencez par écrire des tests unitaires et essayez d'avoir une couverture aussi élevée que possible. Quelqu'un a mentionné TDD, mais j'irais avec BDD .

À la fin, vous dépenserez probablement 80% pour le débogage de bogues complexes.

Comment passer moins de temps à déboguer? Écrivez moins de code.

Sérieusement, tant que vous écrivez du code, vous devrez le déboguer. Les tests unitaires, etc. aident énormément, mais ne pensez pas que vous n'en supprimerez jamais le besoin.

Comprenez le quoi et le pourquoi avant de commencer à écrire du code. Ensuite, utilisez systématiquement une méthodologie. La méthodologie que vous choisissez n'est pas aussi importante que l'utilisation répétée et cohérente de la méthodologie. Si vous voulez toujours de bons résultats, vous devez toujours faire un bon travail et avoir une «méthode à votre folie» est la première étape pour obtenir ces résultats. Au fur et à mesure que vous identifiez les problèmes, vous pouvez ajuster votre méthodologie selon vos besoins et, au fil du temps, vous améliorerez votre processus de développement et, espérons-le, moins de bogues et plus de développement nouveau et significatif.

Lisez attentivement votre code avant même de le compiler. Une lecture très attentive pour la syntaxe et la fonctionnalité. Il peut être étonnamment informatif et est également un bon indicateur si une section de code est trop compliquée.

La plupart des réponses semblent axées sur la façon de réduire le nombre de problèmes que vous devez déboguer, ce qui est précieux. Cependant, le débogage sera toujours nécessaire, il est donc utile de chercher des moyens d'accélérer le débogage.

• Sachez utiliser votre logiciel de contrôle de version.

  • L'utilisation de branches vous aidera à séparer les domaines de développement et vous pourrez voir quel domaine de développement a le bogue et lequel n'en a pas.
  • Apprenez à utiliser la bissection dans votre VCS, Git a cela intégré. Si vous utilisez un autre VCS qui n'a pas de bissection intégré, recherchez un outil qui fonctionne comme git bisect mais pour votre VCS (je sais que cela existe pour SVN et ne devrait pas être trop difficile à créer pour d'autres VCS). Cela vous aidera à vous limiter au changement de code qui a introduit le bogue, ce qui vous aidera à savoir où pointer votre débogueur. Ce processus de bissection sera plus rapide si vous avez des tests pour le bogue et savoir quel commit contient le changement incriminé sera plus utile si vous pratiquez les commits atomiques.

• Améliorez votre compréhension du langage de programmation que vous utilisez.

  • Lisez des livres, des blogs et du code sur le langage de programmation.
  • Chaque fois que vous corrigez un bogue, assurez-vous de bien comprendre pourquoi le code n'a pas fonctionné et pourquoi votre correctif fonctionne. Au fil du temps, vous apprendrez de nombreux accrochages dans votre langue, ce qui vous aidera à éviter leurs problèmes et à en repérer les symptômes en cas de réapparition.

• Soyez logique

  • Ne changez pas plus d'une chose à la fois sinon si le comportement change, vous ne saurez pas quel changement a causé le changement de comportement.
  • Vérifiez vos hypothèses.

Ajout aux commentaires pour Unit Testing mais ce n'est vraiment bon que si votre code a été séparé pour le supporter (par exemple MVC). Si vous ne pouvez pas implémenter MVC (ou similaire) (projet hérité), les tests unitaires ne fonctionnent pas du tout pour votre interface utilisateur. J'ajouterais ensuite des tests d'interface utilisateur automatisés (Microsoft Coded UI Tests, WaitN) car cela réduira les erreurs dans cette partie de votre code.

Je recommande également fortement d'utiliser des outils d'analyse statique (par exemple FxCop / Microsoft Code Analysis, Resharper, JustCode pour le monde MS). Ceux-ci peuvent trouver toutes sortes de problèmes de codage courants qui peuvent réduire les tâches de débogage idiotes et se concentrer davantage sur le débogage de la logique métier.

Faites-le fonctionner, puis faites-le vite, puis faites-le joli. La plupart des bogues proviennent des premières optimisations ou de la refactorisation de lignes de code qui étaient totalement correctes. Si vous optez pour l'orientation d'objet, ne vous répétez pas, restez simple et faites toujours des vérifications d'intégrité des plages de valeurs, surtout si vos méthodes fonctionnent toujours avec des contraintes. Cela ne vous aidera pas à faire moins d'erreurs mais cela vous aidera probablement à repérer les bogues plus rapidement et donc le débogage prend moins de temps.

J'ai beaucoup réfléchi à ce problème récemment - la réponse simple est d'aller lire La conception des choses de tous les jours de Don Norman; Écrivez le code comme vous concevriez un produit.

Pour paraphraser, une bonne conception minimise les erreurs. Cela signifie, quelques choses, dont la plupart vous faites déjà (même si vous ne savez pas exactement pourquoi ).

-Nom fonctionne intuitivement. C'est ce que l'on appelle officiellement l'accessibilité. C'est-à-dire qu'un bouton permet d'être pressé, un levier permet d'être commuté, une poignée à tirer, etc.

-Rendre difficile d'écrire du mauvais code. Recherchez les mauvaises entrées et lancez les erreurs le plus tôt possible, utilisez des applications hongroises le cas échéant, etc. Ces fonctions sont appelées fonctions de verrouillage.

-Utilisez l'abstraction le cas échéant. La mémoire à court terme est faible.

-La documentation est évidemment importante, mais c'est la moins efficace pour s'assurer que le code est utilisé correctement. En bref, les produits bien conçus n'ont besoin d'aucune documentation. (La façon la plus évidente de voir cela est de regarder de mauvais exemples: à savoir, les portes avec poignées que vous êtes censé pousser.)

-Tests unitaires. Ceux-ci n'empêchent pas vraiment les erreurs, autant qu'ils rendent évident où se trouvent les bogues et fournissent une raison.

Je suis sûr que je manque beaucoup d'autres principes, mais le point est, lisez la conception de l'erreur.

La meilleure façon de réduire le débogage, IMO, est de se concentrer et de ralentir lors du codage. Cela vous oblige à voir les erreurs que vous avez pu commettre!

Bien que je soutienne totalement les tests unitaires suggérés ci-dessus, TDD ou BDD seront d'une grande valeur car vous devez d'abord réfléchir au problème et à la solution.

Mais personnellement, pour moi, prendre quelques minutes juste pour s'asseoir tranquillement et réfléchir au problème et à la façon de l'aborder ainsi que les avantages et les inconvénients de chaque approche, fait des merveilles pour ma qualité de code et aide à vider mon esprit d'encombrement.

Parfois, un gribouillage rapide sur un morceau de papier vous aide à voir les plus grandes pièces connectées du puzzle.

J'écris le pire code quand je plonge la tête la première et frappe le clavier. Un peu de réflexion et de contemplation fait toute la différence.

PS. Je veux dire 5 peut-être dix minutes, pas des heures à écrire une énorme spécification.

Quelques bonnes réponses déjà, juste un peu plus de nourriture, bien qu'en plus de ce que d'autres ont dit.

Apprends de tes erreurs. Ne continuez pas à faire les mêmes encore et encore.

Assurez-vous de couvrir les cas marginaux lors de la programmation - ce sont des endroits où il y a souvent des bogues.

Faites attention à l'exigence. Même si cela fonctionne mais ne répond pas aux exigences spécifiées, c'est un bug.

Les journaux d'exceptions peuvent être d'une réelle aide en cas de problème dans six mois. Prenez l'habitude d'enregistrer les exceptions.

Mes deux principales pensées sont 1) Écrivez un meilleur code qui échouera lorsque vous faites quelque chose d'inattendu 2) Devenez meilleur au débogage

Mon code est jonché de

if(value!=null) throw new NotImplementedException();
if(obj.v>0) throw new Exception(); //sometimes i dont write NotImplementedException
if(value=="thing") throw ...;

Chaque fois que j'exécute ce morceau de code, une exception est levée, ce qui provoque l'arrêt du débogueur, ce qui me permet de coder dans les nouvelles fonctionnalités ou d'éviter les conditions plutôt que de me tromper sur ce qui se passe / avoir un bug

Pour mieux déboguer avec la pile d'appels, les points d'arrêt (avec conditions), la fenêtre immédiate (également appelée fenêtre d'invite ou de repl), les variables de «surveillance» et tout le reste.