Devenir un meilleur correcteur de bogues

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?

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.

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 .

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

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.

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

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!

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.

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?

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.

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.

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.

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 .

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.