Devenir un meilleur correcteur de bogues

24

J'adore être programmeur. Là, je l'ai dit. Cependant, cela dit, j'ai réalisé récemment que je ne supporte vraiment pas la correction de bugs. Du tout.

En fait, pendant que je développe quelque chose, ma productivité est extrêmement élevée. Même lorsque j'écris des tests unitaires et que je fais des autotests de mon développement, je suis généralement très productif. Je peux bien me concentrer et je peux accomplir des tâches.

Cependant, lorsque le temps de l'AQ arrive et que je travaille sur la correction de bugs, mon inspiration prend une énorme chute. Je dois me forcer avec des mesures assez extrêmes (vous savez, une musique BPM élevée, des quantités excessives de caféine, etc.) pour faire quoi que ce soit . Mon travail consiste généralement à entrer dans un projet massif existant et à ajouter de nouvelles fonctionnalités ou à corriger des bugs, donc je ne peux pas dire exactement à mon employeur que j'ai besoin de quelques semaines pour écrire des tests unitaires pour l'ensemble de leur code :) La technologie de serveur que nous utilisons souvent est très prohibitive pour les tests unitaires et d'intégration, car elle présente de nombreux problèmes de chargeur de classe Java. Je ne suis pas complètement contre la correction de bugs, parfois cela peut être amusant, mais ce n'est pas amusant du tout lorsque vous devez apporter des modifications mineures et attendre 30 secondes à 3 minutes pour pouvoir voir si elles ont fonctionné ou non (en raison du fonctionnement du système).

Comment puis-je améliorer ma productivité et ma motivation lors de la correction de bugs? Est-ce quelque chose que la plupart des programmeurs traitent?

Naftuli Kay
la source
4
"Je ne peux donc pas dire exactement à mon employeur que j'ai besoin de quelques semaines pour écrire des tests unitaires pour tout son code" . Y at-il une raison à cela? Je fais beaucoup ça, et ça rapporte vraiment à tout le monde. Je veux dire, si vous prenez 3 semaines pour le test unitaire, vous pourriez simplement économiser 3 semaines de correction de bogues. Habituellement, je trouve même des tas de bugs éventuels qui sont totalement passés sous le radar de QA. Bien sûr, vous ne voulez probablement pas faire cela tout seul.
netcoder
10
N'écrivez pas de bogues dans votre code ... problème résolu.
Michael Brown
3
Je préfère presque corriger les bugs que d'écrire du nouveau code. Je le préfère particulièrement à l'écriture de tests unitaires. Peut-être que je suis bizarre.
Paul Tomblin
1
@PaulTomblin Je comprends ce que vous dites. Je connais des développeurs qui aiment le développement frontend ... moi j'aime le code non-UI le meilleur. Il est parfois difficile d'écrire un nouveau code parce que vous obtenez parfois un «bloc d'écrivain»
Michael Brown
1
Il est difficile de mesurer la «productivité» de la correction de bugs car vous pourriez passer beaucoup de temps à découvrir ce qui n'est «pas le problème», tout comme Edision est censé avoir dit avoir trouvé «1000 façons de NE PAS fabriquer une ampoule ", et je pense que les non-correctifs sont souvent instructifs pour vous enseigner quels indices sont importants et la tâche actuelle (et future) de correction de bogues.
Zeke Hansell

Réponses:

21

ce n'est pas amusant du tout quand vous devez apporter des modifications mineures et attendre 30 secondes à 3 minutes pour pouvoir voir si elles ont fonctionné ou non

Voilà le vrai problème ici. Vous vous sentez improductif quand vous devez attendre si longtemps pour obtenir des commentaires, je connais le sentiment. Il est peut-être possible de simuler davantage de services et de créer de meilleurs outils de test afin d'obtenir des commentaires immédiats.

Le test d'unité de code hérité est coûteux ou peut impliquer des refactorisations dangereuses. Cependant, la création de meilleurs appareils de test peut vous permettre de tester manuellement en quelques secondes par rapport à quelques minutes et vous pouvez obtenir presque la même productivité que de travailler avec un nouveau code testable unitaire.

Attendre si longtemps les commentaires est ennuyeux et démotivant, pas l'acte de corriger les bogues lui-même.

Garrett Hall
la source
Avez-vous déjà lu le Mythical Man-Month? Imaginez simplement attendre jusqu'au lendemain matin et essayer d'analyser le contenu de la pile de vidage / enregistrement qui était présent au moment de l'échec ...
sq33G
@ sq33G Ou pire encore, avoir votre équipe de test en Inde à qui vous ne parlez que par e-mail (histoire réelle).
Garrett Hall
13

La correction de bogues est une compétence extrêmement importante que vous devez apprendre. J'ai lu quelque part que, normalement, on passe 80% du temps à résoudre les 20% des problèmes dans une application.

Je crois qu'il faut apprendre des erreurs et la correction des bogues est une opportunité d'apprendre des erreurs des autres . Vous pouvez prendre cela comme un apprentissage et vous aider à devenir un meilleur programmeur à l'avenir. C'est la motivation que j'avais lorsque j'ai commencé à corriger de nombreux bugs et à progresser vers la refactorisation du code .

ManuPK
la source
1
Ce que vous écrivez est vrai; cependant, votre 80% / 20% n'est vrai que parce qu'il y a tellement de code merdique dans la nature. Par merde je veux dire, sous-conçu ou sur-architecturé ou mal architecturé ou tout simplement des pratiques bâclées (programmation crack-head). Cela étant dit, il n'y a rien de mal à ce qu'un développeur préfère le développement à la correction de bogues. Ajoutez au fait que la plupart des logiciels sont mal conçus dès le départ et que vous configurez déjà la plupart des correcteurs de bogues en cas d'échec.
Wil Moore III
@wilmoore: Vous avez raison avec le code merdique, et il y a aussi une exigence changeante.
ManuPK
6

Personnellement, j'ai trouvé utile d'arrêter de considérer les bogues comme de `` petites choses '' mais plutôt comme de gros showstoppers qui sont tout aussi importants que des fonctionnalités énormes, même si elles impliquent simplement de changer quelques lignes de code après des heures de débogage. De cette façon, avoir passé une journée entière à tuer 3 entrées de suivi des bogues est beaucoup moins déprimant (l'approche dépend un peu de votre capacité personnelle à vous convaincre de le croire :-).

Peut-être que cela aide à en faire un jeu, par exemple avec vos collègues ( qui corrige le plus de bugs par jour? Ou, pire encore, qui a fait le moins de reconstructions par jour? )

Alexander Gessler
la source
Je ne suis pas du tout d'accord avec l'idée d'en faire un jeu de correction du plus grand nombre de bogues en une journée, ou autres. Certains bugs sont simples à isoler et à corriger une fois que vous savez comment les déclencher: collez cette valeur particulière dans ce champ, et regardez: la longueur restante est maintenant incorrecte. (Peut-être que vous comptez des octets au lieu de caractères et que vous avez oublié l'espace ci-dessus, par exemple, U + 007F.) D'autres (en particulier les bogues impliquant diverses conditions de concurrence ou multithreading) peuvent facilement prendre des jours de travail pour se reproduire, mais être critiques lorsqu'ils le font se produire sur le terrain. Cependant, ils ne garantissent qu'une seule entrée dans le suivi des bogues.
un CVn
Compter ces bogues de manière égale signifierait que tout le monde corrigerait simplement les bogues simples plutôt que de s'attaquer aux conditions de course, c'est-à-dire. :-) Ne pas laisser les bogues "durs" reposer sur des choses simples est un sujet totalement différent.
Alexander Gessler
Il y a aussi la question de la qualité du correctif. Dans de nombreux cas, vous pouvez apporter un correctif rapide à un bogue sans arriver à la cause, mais une erreur similaire apparaît alors à un autre endroit ou dans une autre situation. Comprendre et corriger la nature de l'erreur prend souvent plus de temps, mais conduit généralement à une solution beaucoup plus robuste. À moins que ce soit "cela échoue tout le temps en production et que nous devons publier un correctif maintenant ", je sais quelle approche je préférerais (et même si c'est le cas, revenir en arrière pour réparer l'os cassé plutôt que de simplement bandaider la coupe serait une bonne idée).
un CVn
5

J'ai été à ta place. Créez des tests automatisés quand et où vous le pouvez. Cela ne doit pas être tout d'un coup. Lorsque vous trouvez un bogue, prenez une minute pour essayer de programmer un cas de test. Si vous ne pouvez pas programmer un cas de test, écrivez un texte explicatif quelque part sur la façon de le tester manuellement, par exemple cliquez ici, saisissez ceci, etc. et placez-le dans une sorte de base de connaissances.

Le débogage peut être très fastidieux, surtout avec du code compliqué que vous n'avez pas écrit. Venez avec un objectif, "Fix Bug 13533 by Friday". Ensuite, configurez une récompense si vous atteignez l'objectif, "Prenez une pinte avec mes amis vendredi soir". Cela aidera à le rendre un peu plus gratifiant.

A part ça, parfois le travail n'est que ça ... du travail.

Michael Rice
la source
Pour ce projet en cours, j'ai, en fait, écrit des tests unitaires. Le seul problème est que, quoi que je puisse prouver à l'aide de mes tests unitaires, tout va au diable en production / vie réelle, en raison des problèmes avec la technologie du serveur. Malheureusement, il n'y a pas d'autre alternative et je ne suis pas en place pour changer le moteur, pour ainsi dire.
Naftuli Kay
Vous devez écrire une routine "gestionnaire d'erreurs inattendues" pour vous aider à les rattraper ;-)
Zeke Hansell
2

Dans ce type de situation, vous avez besoin d'une sorte de défi créatif. Normalement, il écrit du code, mais ici ce n'est pas le cas.

Mais tout n'est pas perdu. Travaillez à résoudre vos méta-problèmes et investissez votre énergie dans cela. Pourquoi faut-il de 30 secondes à 3 minutes pour obtenir des commentaires? Comment pouvez-vous raccourcir ce temps? (Peut-être que vous pouvez écrire une sorte de script ou d'application utilitaire que vous ne consignez pas qui vous aide à le faire). C'est votre nouveau domaine problématique - votre nouveau défi créatif.

Personnellement, à chaque fois que je suis dans une phase de correction de défauts, j'identifie mes principaux obstacles pour le faire rapidement et sans douleur, et j'automatise ce que j'ai besoin d'automatiser pour supprimer ces obstacles. Cela se traduit souvent par une productivité accrue et des ajouts à mon portefeuille personnel pour démarrer.

Donc, en bref, je dirais «toujours en développement». :)

Erik Dietrich
la source
Je t'entends. J'aimerais pouvoir faire quelque chose pour automatiser les choses. J'ai un serveur et un client, et je ne peux pas automatiser exactement le client facilement. Il y a plusieurs étapes dans le flux de travail de cette chose et de nombreux bugs surviennent entre les étapes, donc je dois faire une étape de 30 secondes, puis une étape de 3 minutes, ou inversement. En bout de ligne, c'est assez cauchemardesque :) :)
Naftuli Kay
2

Votre problème est-il le débogage ou la correction de bogues? Si vous pouvez déboguer suffisamment pour isoler le composant à l'origine du problème, considérez-le comme une nouvelle tâche de développement.

  1. Écrivez des tests unitaires pour le morceau de code qui casse. Assurez-vous que vous disposez de tests validant toutes ses fonctionnalités souhaitées, ainsi que certains qui isolent particulièrement le comportement du buggy.
  2. Écrivez un nouveau code qui réussit tous les tests que vous venez d'écrire.
  3. Remplacez l'ancien code par le nouveau.
  4. Exécutez des tests d'intégration. C'est là que vous exécuterez vos redémarrages de serveur de trois minutes, mais cela devrait être minimisé si vous avez bien effectué les étapes 1 à 3.
  5. Voila!
Matthew Flynn
la source
2

Vous devriez peut-être consulter le Debugging Myself de Brian Hayes , un article paru dans American Scientist en 1995. Vous pouvez prendre des mesures (comme l'utilisation habituelle des conditions Yoda ) pour réduire ou éliminer les types de bogues les plus détestés que vous produisez.

Je suis d'avis que le débogage est une compétence différente de la programmation, bien que liée. En particulier, le débogage de programmes multithread est presque entièrement différent de leur écriture.

Bruce Ediger
la source
1

Si le développement de logiciels est ennuyeux, vous le faites mal. En d'autres termes, ce n'est pas un problème avec vous, mais un problème avec votre plate-forme et votre processus. Avez-vous envisagé de chercher un poste en utilisant un langage dynamique (par exemple Python, Ruby, JavaScript), où vous n'avez pas à attendre le redémarrage du serveur?

Kevin Cline
la source
Malheureusement, ce n'est pas une option à ce stade. De plus, le flux de travail, comme mentionné ci-dessus, nécessite plusieurs étapes et étapes et les bogues émergent entre ces étapes. Si j'écrivais cela à partir de zéro, j'essaierais certainement d'utiliser un langage de script, mais nous sommes coincés avec ce que nous avons pour l'instant.
Naftuli Kay
1
@TK: Dans ma dernière entreprise, nous avons eu beaucoup de succès en intégrant Groovy dans notre processus de développement Java pour automatiser des processus autrefois manuels. Ce n'est pas Java, mais c'était assez proche et si efficace que nous avons eu très peu de recul.
kevin cline
1

Cela fait partie du travail, malheureusement. Vous aurez des projets de merde et des employeurs de merde (je ne dis pas que ce soit le cas ici, juste en généralisant).

Vous pouvez écrire des tests unitaires par rapport à leur code. Glissez-le comme vous le pouvez. Une fois que vous aurez quelque chose à montrer aux patrons, vous pourrez peut-être inverser la tendance.

Utilisez des outils de débogage pour corriger la lenteur, utilisez des tests unitaires pour tester le nouveau code et utilisez-les pour résoudre les problèmes de code existant ainsi que pour décomposer le code existant en morceaux plus petits.

Vous pouvez en faire un défi et devenir un héros de l'amélioration des processus. Et, si cela ne fonctionne pas, vous aurez une bonne expérience à apporter au prochain employeur.

Alan Delimon
la source
1

La plupart des programmeurs doivent faire face à des problèmes personnels de correction de bogues à un moment donné de leur carrière.

Le bon sens de la distance entre la personne et le travail est essentiel pour votre motivation. Ne sous-identifiez pas ou ne sous-identifiez pas votre travail. Si vous vous identifiez trop à votre travail, des problèmes tels que ceux que vous avez décrits peuvent apparaître: vous pourriez être très réticent à corriger les bogues, car vous êtes la moitié du temps à vous blâmer. Obtenez une certaine distance intérieure et découvrez comment vous pouvez résoudre votre problème de manière rationnelle.

En ce qui concerne les problèmes particuliers de votre plate-forme, il existe plusieurs façons d'atténuer les longs délais de déploiement et de test (et, d'un côté, les vôtres ne sont pas particulièrement longs).

Premièrement, plus votre temps de test est long, plus vous devriez être opposé au culte du fret. Si vous effectuez un changement, pensez-y jusqu'à ce que vous soyez sûr qu'il corrigera le bogue . Bien sûr, à quel point la confiance est soumise à la durée de votre cycle de test. Mais si vos cycles de test s'allongent et que de longs tests ne peuvent être évités, passez plus de temps à réfléchir et vous serez récompensé et plus heureux dans le débogage car il est plus rapide et a l'effet gratifiant d'un bon moment de "fiat lux" ".

Deuxièmement, privilégier davantage les tests unitaires et moins les tests d'intégration. Supprimez tous les points de défaillance de la plate-forme difficile à déboguer.

thiton
la source
1

La correction des bogues peut être "géniale" ou "fastidieuse". J'ai des crédits de jeu qui sont entièrement dus à la correction d'un seul bug - le bug de plantage que personne d'autre ne pourrait corriger. Mais l'entretien quotidien de bugzilla est ahurissant. Les bugs mineurs sont fastidieux. Les bugs majeurs en valent la peine.

Voici la réalisation: Le fait que vous ayez une liste géante de bogues mineurs est en soi un bogue majeur. Ce n'est tout simplement pas un bug de code. C'est un bug de processus ou de gestion.

Trouvez ce bogue et corrigez-le.

Jamie
la source
1

Une chose que j'ai trouvée parmi les collègues et acquéreurs qui sont de bons "débogueurs / correcteurs de bugs / résolveurs de problèmes" est qu'ils aiment généralement résoudre des énigmes. Cela peut signifier des mots croisés, des jeux de nombres (comme Sudoku) et des puzzles de logique, etc.

Donc, une façon de devenir un meilleur correcteur de bogues serait de passer du temps à travailler sur vos compétences en résolution de problèmes ou en casse-tête.

Voici un lien Wikipédia qui pourrait être un bon point de départ pour vous aider à mieux résoudre les problèmes.

Attention, certaines personnes sont tout simplement meilleures en résolution de problèmes, ou elles l'apprécient tout simplement plus. Certaines personnes ne l'aiment pas du tout, ce qui rend difficile de vous forcer à faire - mais ne vous y trompez pas - si vous vous forcez à apprendre à résoudre des énigmes, il sera plus facile d'être un bon correcteur de bugs à l'avenir .

Zeke Hansell
la source
0

La correction des bugs se sent généralement comme une corvée car elle peut vous donner l'impression que les bugs prennent tout votre temps et vous éloignent des nouvelles choses amusantes. La réalité est cependant que la correction de bogues est une très grande partie de ce que nous faisons, et cela commence dès l'écriture de la première ligne de code et l'exécution du compilateur. Lorsque vous publiez du code pour la première fois, vous avez probablement déjà passé des heures à corriger des bogues, mais cela ne semble pas être le cas car vous les avez corrigés dans le cadre du processus d'implémentation des fonctionnalités. De façon réaliste, peu importe la qualité de votre programmeur, les bogues se glisseront dans votre système.

Alors, comment vous rendez-vous amusant? Eh bien, je ne peux pas vraiment répondre à cela car je ne peux vraiment pas imaginer ce qui fait flotter votre bateau individuel. Pour moi, je suis un peu accro aux outils, donc la réponse a été d'avoir une chaîne d'outils très fiable et un processus de développement flexible qui contribuent tous à faire de la correction des bogues moins une corvée, et plus simplement un problème à résoudre rapidement. Je développe actuellement principalement en C #, et je suis toujours à la recherche d'outils qui élimineront les parties fastidieuses du logiciel d'écriture. J'utilise une première approche de développement de test prise en charge avec une très bonne API BDD appelée StoryQ . J'utilise Resharper pour automatiser une grande partie de mon refactoring et StyleCop pour garder un couvercle sur des choses comme le style de codage. Mon dernier ajout à la chaîne d'outils a été d'inclureNCrunch qui exécute mes tests en continu et simultanément en arrière-plan pendant que je code, et c'est vraiment NCrunch qui s'est avéré être le changeur de jeu.

La combinaison de tous ces outils a récemment vu ma productivité passer à travers le toit, car je perds très peu de temps à attendre que les choses soient compilées ou exécutées. Je reçois un retour visuel instantané au sein de mon IDE pour me faire savoir que j'ai des problèmes à résoudre, et je présente mon code de test de telle manière que je puisse localiser en quelques lignes de code l'endroit exact où non seulement le l'échec se produit, mais à l'endroit où la cause de l'échec se produit en raison des beaux rapports verbeux que je reçois de StoryQqui me dit exactement quelles parties de mon test réussissent, qui échouent et où dans le code les échecs sont. Avec tout le temps perdu de mon temps de développement, je passe très peu de temps à déboguer activement, et plus de temps à résoudre des problèmes et à écrire des tests et du code. Les problèmes de roulement élevé me tiennent occupé et apportent beaucoup de variation dans mes tâches. Cela m'a également donné beaucoup de temps pour poursuivre d'autres domaines d'intérêt au cours de ma journée de travail afin de pouvoir injecter des idées nouvelles et innovantes dans notre gamme de produits et nos processus.

S.Robins
la source