Que faire lorsque vous avez épuisé toutes les possibilités de corriger un bug

Je suis un programmeur junior (4 mois d'expérience de carrière jusqu'à présent) travaillant sur une application mobile multiplateforme (équipe d'une personne - donc c'est juste moi-même).

J'ai un bug dans ce programme / application qui est assez grand (30 fichiers d'en-tête différents, chacun avec son propre fichier cpp aussi). J'ai essayé de retrouver exactement ce qui se passait avec le bogue et aussi de le corriger (j'ai même essayé d'utiliser des hacks pour le faire fonctionner) mais d'environ une douzaine de solutions ou plus (j'ai des idées sur ce qui cause le problème) ) Je suis arrivé avec rien ne m'a conduit à suivre exactement ce qu'est le bogue ou corrigé le bogue.

Avez-vous des conseils à donner à un programmeur débutant sur certaines techniques générales (faites un tour, imprimez tout mon code sur du papier et parcourez-le avec un stylo, etc.) que je pourrais utiliser pour m'aider avec ce bug?

Pour donner un peu plus de contexte à mon bug; cela implique l'API multiplateforme Mosync, lorsque j'effectue une séquence spécifique d'actions, l'écran actuel ne redessine pas (et il apparaît) que l'écran précédemment affiché reçoit toujours les événements de pression du pointeur / touche et non l'écran actuel.

Séquence spécifique:
- Écran de menu affiché - cliquez sur "Afficher le bouton des commandes précédentes"
- Écran de commandes précédentes affiché - cliquez sur "Charger le fichier" puis cliquez sur le bouton de menu et ouvrez l'écran de
livraison - Écran de livraison affiché - cliquez sur le bouton de menu et ouvrez l'écran d'
achat - Écran d'achat affiché - Erreur ici, l'entrée de cet écran n'est pas affichée / n'a pas réagi, ListViews ne défile pas, les boutons ne réagissent pas aux clics, les cellules ListView ne répondent pas aux clics

J'aimerais aussi avoir une autre paire d'yeux pour passer en revue mon travail et signaler le bug, mais comme je l'ai dit, je suis une équipe de 1, mon patron me dirige, il est propriétaire de l'entreprise et a des idées pour une application, mais ne le fait pas ne connais pas non plus le c ++ ou les langages récents (cobal? je pense que c'est tout). Des conseils sur la façon d'obtenir une deuxième paire d'yeux sans violer / montrer le code / la propriété intellectuelle de l'entreprise?

... et ne pas quitter ce stage rémunéré n'est pas une option, le contrat dit que si je pars avant 6 mois d'un contrat de 12 mois, je suis susceptible de payer 30% de mon salaire annuel

Si vous pouvez reproduire le problème 100% du temps, définissez un point d'arrêt à la dernière étape (le plus tôt possible). Si vous parcourez toute la pile des appels, je suis sûr que vous allez trouver des valeurs inattendues quelque part, ou quelque chose qui devrait être appelé mais qui ne l'est pas.

Éditer:

Et si vous êtes assis à la fin de votre esprit en essayant de corriger le bug et l' affichage ici en espérant que vous aurez quelques conseils lumière resplendissante, à pied . Sortez la tête et revenez plus tard (de préférence demain ou après le week-end). Il y a eu de nombreuses fois que j'ai passé une journée entière à chercher une solution à un problème particulier juste pour repartir, revenir le lendemain avec la tête claire et la trouver dans les dix minutes.

Le débogage consiste davantage à isoler et à comprendre exactement quel est le problème (par rapport à l'application d'un correctif)

Une chose à faire attention lors du débogage est si vous commencez à voir que vous sautez après différentes théories, car cela prend souvent plus de temps et n'élimine pas systématiquement les problèmes possibles.

Habituellement, la meilleure façon de déboguer ces types de situations est l'approche systématique ennuyeuse en décomposant votre système en petits morceaux et en faisant fonctionner chaque pièce isolément et en ajoutant chaque élément de complexité un par un jusqu'à ce qu'il se casse. Ensuite, vous avez isolé le problème exact. Cette méthode peut sembler un peu fastidieuse et un travail plus poussé, mais elle supprime les variables et garde votre cerveau sain d'esprit tout en essayant de déboguer un logiciel complexe.

Ce ne sont que quelques choses que j'ai faites dans le passé, évidemment elles ne fonctionneront pas toutes dans toutes les situations:

1. Sachez que ce n'est que du code, et quelque part il y a un bug (ce n'est pas seulement de la magie noire) que vous POUVEZ corriger.
2. Prendre une pause.
3. Parcourez le code très lentement, analysez chaque étape et assurez-vous de bien le comprendre et ce qu'il fait, sans passer outre.
4. Obtenez une deuxième paire d'yeux pour regarder le problème.
5. Dormez et oubliez ça jusqu'à demain (éclaircissez la tête), venez avec une nouvelle perspective).
6. Imprimez votre code et analysez chaque ligne en prenant des notes dans les marges, en comprenant chaque implication de chaque ligne
7. Si ce n'est pas un bug critique, mais provoque des erreurs que l'utilisateur n'a pas besoin de connaître, j'ai (honteusement, mais honnêtement) piégé le bug et l' avalé ! Si ce n'est pas dangereux et que vous ne pouvez pas en trouver la cause, parfois vous vous contentez de le piéger et vous ne laissez rien savoir à l'utilisateur. C'est tout sur le retour sur investissement pour le client, et parfois cela n'en vaut pas la peine.
8. Dites verbalement au bogue que vous allez le traquer et le tuer. Parfois, il s'enfuira. :-)

J'ai généralement cette approche lors de la résolution de bugs.

1. Créez une belle étape par étape pour reproduire le bogue
2. Simplifiez l'étape par étape
3. Où dans le code se produit le bogue? Comme quelles fonctions sont impliquées?
4. Quel chemin choisit le code lorsque le bogue se produit, la chaîne d'appel.
5. Concentrez-vous sur l'emplacement, quand est-ce ok quand n'est-ce pas. Répétez ensuite cette opération jusqu'à ce que vous trouviez exactement l'endroit où l'erreur s'est produite.
6. Pourquoi cela arrive-t-il?

À ce stade, il est généralement assez clair de ce qui s'est passé depuis que j'apprends tellement de choses en me concentrant sur le problème, donc je sais quoi faire. Ou j'ai une question assez ciblée que je peux poser dans un forum.

Ensuite, j'essaie de résoudre le problème et j'utilise l'étape par étape que vous avez créée à l'étape 1 pour vérifier si le bogue est corrigé.

Tous les conseils précédents sont excellents, et une grande partie vise à vérifier les hypothèses sur le bogue / l'erreur, puis à suivre un processus de débogage pour localiser l'erreur (parfois en examinant l'environnement autour du bogue et parfois directement dans le code).

Cette approche ne fonctionnera pas toujours, indépendamment de votre ancienneté ou de votre expertise. Parfois, vous avez juste besoin d'un autre regard sur le problème. Trouvez quelqu'un pour examiner le problème ou déboguer la session avec vous - souvent, le simple fait de parler du code vous mènera à l'erreur.

Comme d'autres l'ont dit 1) être capable de le reproduire de manière fiable et 2) avancer dans un débogueur jusqu'au point où cela se produit.

Si je ne peux pas le faire, pour une raison quelconque, j'ai deux autres méthodes qui nécessitent toutes deux d'avoir une version différente du code qui ne présente pas le bogue.

1. Exécutez les deux versions du code côte à côte sous les débogueurs. Faites-les avancer jusqu'à ce que le mauvais fasse quelque chose de différent du bon.

2. Alterner l'exécution des bonnes et des mauvaises versions du code. Avoir un diff ou une autre liste des différences entre les versions. Modifiez ensuite de manière incrémentielle le code de l'une ou l'autre version pour qu'elle corresponde mieux à l'autre. Si le mauvais devient bon, ou le bon devient mauvais, je renonce au changement et fais un plus petit changement. De cette façon, je rentre chez moi sur le bug. Je pense que c'est "se mettre des deux côtés du problème et travailler vers le centre". Cette méthode ne nécessite pas de débogueur.

Si le problème est difficile à reproduire, alors je besoin autant d' informations que je peux obtenir, comme une décharge de la pile, quand il ne se produit. Je m'assure donc de pouvoir obtenir ces diagnostics, d'attendre que le problème se produise et j'espère avoir suffisamment d'informations pour le trouver.

Si vous étiez chargé de faire le travail sur place en tant que programmeur junior, il y a au moins une personne qui pensait que vous étiez capable de tout gérer vous-même.

Ensuite, avant de demander de l'aide à vos supérieurs, notez sur un papier brouillon la liste des étapes / méthodes que vous avez suivies pour retracer le bug, jusqu'où vous en êtes allé, pourquoi vous avez abandonné chaque méthode et qu'avez-vous appris à chaque tentative. Résumez également ce que vous avez appris sur le projet jusqu'à présent.

Il y a de fortes chances que, lorsque vous avez fini d'écrire ceci, ce qui peut être fait devienne aveuglément évident. Si c'est le cas, vous devez simplement suivre ce qui s'est révélé afin de reproduire le bogue et essayer de le corriger. Si ce n'est pas le cas, vous disposez d'un fondement sur lequel vous pouvez parler avec vos supérieurs. Si vous demandez leur aide sans montrer ce que vous avez fait, ils pourraient avoir une impression négative sur vous.

Mais, si vous vous éclaircissez la tête, revenez après le week-end, vous pourrez peut-être le résoudre en un rien de temps, sans l'aide de personne. Cela arrive tout le temps.

Nous devons savoir à quel point il est difficile de se reproduire, car la méthode est très différente. Pour un défaut reproduit de manière fiable, automatisez la cause du défaut. Utilisez des débogueurs et des traces de débogage (les traces ont le moins d'impact sur les défauts de type condition de concurrence). Soyez méthodique. Une étape à la fois, chaque étape fournit plus d'informations, même si elle confirme ce que vous savez déjà. Si vous obtenez un résultat surprise, arrêtez-vous, comprenez-le à 100% avant de continuer. Il est douloureusement lent, mais vous mène toujours au résultat final si vous lui donnez suffisamment de temps.

Si vous ne pouvez pas le rediffuser, vous avez un problème, comment confirmez-vous que vous l'avez résolu. Mettez le code de débogage et laissez-le là. Finalement, demandez-vous si "Closed: DNR" est une option valide? (N'a pas pu / n'a pas pu refaire). Dans les affaires, c'est finalement une décision coût / bénéfice.

Ne présumez pas que vos bibliothèques sont correctes, confirmez qu'elles le sont.

Faites une pause, soyez pragmatique quant au coût par rapport au besoin de réparer, et surtout, demandez à quelqu'un d'autre de s'asseoir à côté de vous et de vous aider.

Beaucoup de bonnes réponses ici. Quelques autres conseils:

Les interfaces utilisateur vivent rarement isolées. Créez un programme de test avec l'ensemble minimal de fonctionnalités nécessaires pour reproduire le bogue. Si l'interface utilisateur est bien conçue, vous devriez pouvoir découpler les composants d'interface utilisateur qui échouent et les exécuter de manière isolée dans un programme de test. Pouvez-vous toujours reproduire le problème? Si tel est le cas, le problème est probablement lié à votre structure ou à votre infrastructure d'interface utilisateur. Vérifiez la structure de votre interface utilisateur - faites particulièrement attention aux éléments invisibles. Essayez d'apprendre exactement ce qui se passe lorsque vous cliquez sur ce ListView et qu'il ne répond pas - quels gestionnaires d'événements sont invoqués? Gardez à l'esprit qu'il peut exister des bogues dans le cadre de l'interface utilisateur elle-même - ne sautez pas à cette conclusion, mais ne l'excluez pas carrément. Un test rapide consiste à mettre à niveau votre version de Mosync et à vérifier si les symptômes persistent.

À défaut: que reste-t-il dans votre programme de test? Comprendre tous les composants de ce qui reste, en particulier tous les threads en cours d'exécution. Quelque chose fait la maintenance de la base de données en arrière-plan? Un spouleur de fichiers quelconque? Code de surveillance du comportement des utilisateurs NSA? L'interface utilisateur fonctionne-t-elle avec certains de ces composants (peut-être en coulisse)? De quelles opérations d'arrière-plan dépend l'interface utilisateur?

Pendant que vous lisez le code - ce que vous devriez passer beaucoup de temps à faire, étant donné la difficulté du bogue - faites attention à certaines mauvaises pratiques qui pourraient obscurcir votre bogue. Plus précisément, voyez-vous tout cela?

try {
    SaveTheWorld();
} catch (std::exception& ex) { /* oh it didn't work, let's just ignore it */ }

C'est une pratique incroyablement médiocre et en tant que telle, est assez courante (hé, ça n'a pas planté!). Assurez-vous de mettre à niveau tout code qui le fait pour au moins le journaliser - de préférence, supprimez entièrement la gestion des fausses exceptions. (En règle générale, si vous ne connaissez pas l'exception, vous n'êtes pas prêt à la gérer.) S'il interagit avec des API de style C, surveillez les valeurs de retour de code d'erreur perdues et assurez-vous que vous vérifiez les informations d'état d'erreur à partir des outils avec lesquels vous interagissez.

Étant donné que votre programme de test gère désormais correctement les échecs et que vous avez lu le journal que vous avez ainsi produit, mais rien ne met en évidence le bogue, recherchez les interfaces que vous pouvez tester. Y a-t-il une transaction réseau qui devrait se produire sous les couvertures? Si oui, frappez-le avec Wireshark. Transaction de base de données? Essayez une journalisation des requêtes ou vérifiez l'état du serveur de base de données. Système de fichiers ou partages réseau touchés? Vérifiez les fichiers intermédiaires ou utilisez un débogueur pour tracer les E / S. E / S matérielles? Surveillez et sondez. Soyez empirique. L'interface utilisateur pourrait bien être bloquée sur une opération d'arrière-plan que vous n'avez pas prévue.

Enfin: ne paniquez pas. Restez au frais et gardez une trace de ce que vous avez essayé. Si vous ne le trouvez toujours pas, il faudra qu'il devienne un «problème connu» pour être retrouvé un jour de pluie. Vous aurez besoin de beaucoup de matériel pour justifier cette décision si elle doit aller dans ce sens.

Dans l'ordre des choses, les bogues reproductibles sont (relativement) faciles! Pourquoi? Parce que vous pouvez toujours pirater le code au strict minimum jusqu'à ce que le bogue disparaisse, puis retravailler pour déterminer quel code le provoque. Voilà donc une méthode. C'est reproductible, vous avez la créature sous votre contrôle. Vous pouvez le pousser et l'expérimenter. Vous pouvez même le disséquer si vous le souhaitez.

Votre premier objectif est de comprendre pourquoi le bogue se produit dans votre code. N'essayez pas de le réparer au départ. Essayez juste de le comprendre . Si vous essayez de le réparer sans le comprendre, vous piraterez et introduirez probablement une dette technique , même si vous la résolvez.

Parcourez le comportement de l'application, ligne par ligne. Regardez les valeurs variables. Regardez le flux de contrôle. Où le comportement s'écarte-t-il d'abord de ce que votre compréhension vous dit qu'il devrait être? Comprenez-vous comment le système d'exploitation envoie des événements à votre application? Si vous êtes gêné par un problème de "boîte noire", pouvez-vous obtenir la source des bibliothèques / frameworks compilés, vous permettant de passer à un niveau plus profond si vous le devez?

Avez-vous un commit dans votre système de contrôle de version qui ne produit pas ce bogue? (Vous utilisez le contrôle de version n'est-ce pas?) Si vous avez un tel commit, alors vous pouvez faire une recherche binaire sur l'historique pour savoir exactement où le bogue a été introduit.

Vos objectifs devraient être de (1) comprendre - déterminer la cause et à cette fin, essayer (2) d'examiner, de comprendre le comportement de l'application en détail (3) d'isoler le problème en le faisant disparaître, puis en examinant et en comprenant le delta qui vous a permis de le faire

Mais ne restez pas assis là pendant des semaines si vous êtes vraiment coincé. Vous devez aussi en parler à quelqu'un de votre organisation. Sollicitez de l'aide là où vous le pouvez et au-delà d'un certain point, il vous incombe certainement de dire à la direction que vous sentez que vous avez franchi un obstacle au progrès. Mais vous pourrez probablement résoudre ce problème si vous le touchez sous différents angles, tous axés sur l'apprentissage et la compréhension.