Comment abordez-vous les erreurs vraiment bizarres qui vous laissent perplexe pendant plus de 10 heures? [fermé]

29

Vous les connaissez, ces erreurs qui n'ont aucun sens. Où il semble qu'un gremlin vient de sauter profondément dans vos jetons et de gâcher quelque chose. Faites-vous une promenade, écrivez des choses, appelez un oncle?

Adel
la source
3
Votre description est peut-être correcte - Redémarrez et réessayez!
NoChance
5
postez-le sur stackoverflow bien sûr :)
William
5
Pourquoi avez-vous décidé d'un seuil de 10 heures? C'est beaucoup trop long - si vous n'avez pas une bonne idée de ce qui cause un comportement inattendu dans une heure ou deux, vous avez des ennuis.
Vector
5
"Quand les choses deviennent difficiles, les durs s'endorment et laissent le subconscient y travailler." - anon
Michael Easter
2
1. Demandez à quelqu'un de vous aider. Deux personnes est un must. 2. Limitez-le en utilisant des quantités excessives d'instructions de débogage. Il y avait un fichier dans lequel chaque ligne était précédée d'une macro de débogage pour localiser celle qui était défectueuse.
SF.

Réponses:

9

Pour ces problèmes vraiment horribles, ma stratégie est généralement la suivante.

  • Expérimentez et google. Continuez à essayer de résoudre le problème. La plupart du temps, cela résout le problème en une heure ou moins.

  • Cela n'a donc pas fonctionné. Prendre une pause. Prenez un café, parlez de quelque chose sans rapport avec un collègue. Poussez le problème de votre esprit. Lorsque vous regardez le problème 5 ou 10 minutes plus tard, vous le regardez d'un point de vue légèrement différent. La plupart du temps, cela fonctionne.

  • Dans ce cas, ce n'est pas le cas. Alors, passez encore 10 à 30 minutes à le regarder. Appelez ensuite un collègue. Mais avant de le faire, prenez quelques notes; vous voulez démontrer le problème, le reproduire, puis lister les choses que vous avez essayées, et surtout prouver que vous les avez essayées. Faites donc un essai à sec en premier. Définissez des signets dans le code, fermez tous les documents ouverts superflus, etc. De cette façon, vous pouvez soit résoudre le problème vous-même, soit lorsque vous démontrez le problème, vous ne perdrez pas leur temps.

  • Demandez à votre collègue de vous faire prouver toutes vos hypothèses. ce setter est-il réellement invoqué? Cette méthode rend-elle vraiment ce que vous prétendez être? Vous pensez que cet objet n'est pas nul - montrez-leur qu'il n'est pas nul.

  • La plupart du temps, soit en démontrant le problème, vous vous rendrez compte que vous n'avez pas essayé toutes les possibilités, soit votre collègue verra votre erreur.

  • Si cela ne fonctionne pas, il est temps de devenir sérieux. Documentez exactement ce que vous essayez de faire, ce que vous avez essayé et pourquoi cela n'a pas fonctionné. Envoyez-le par e-mail à tous vos collègues. Publiez-le sur SO. À ce stade, le document devrait être une parfaite question SO.

  • Pendant que vous attendez les réponses, google google google. Essayez chaque permutation de la question que vous avez. Ouvrez un tas d'onglets. Vous n'obtiendrez probablement pas de réponse à ce stade, mais vous cherchez des idées, des possibilités, différentes façons d'aborder le problème.

  • Faites autre chose, si vous avez passé 5 heures sur un problème, il est temps de le laisser pour un autre jour. Vous obtiendrez peut-être une réponse utile. Peut-être que lorsque vous attaquerez le problème le lendemain, ce sera évident.

  • Si rien de tout cela ne fonctionne, il est temps de chercher une solution différente. Vous pouvez peut-être utiliser une méthode différente, une technologie différente. Vous devriez peut-être envisager d'abandonner la fonctionnalité pour l'instant. Facturez-vous le client à l'heure? Travaillez-vous pour une entreprise sur une application interne? Vous devez faire remonter cela au propriétaire et lui dire "regardez, j'ai passé x heures là-dessus et je n'ai fait aucun progrès, le rapport qualité-prix en vaut-il la peine?". Vous ne voulez pas aller voir votre patron et lui dire que vous avez passé 16 heures sur un problème uniquement pour qu'ils se retournent et disent, ce n'est pas si important, sautez-le pour cette version. vous devez le découvrir plus tôt.

  • Et si ça ne marche pas? Eh bien, vos seules options sont de continuer à marteler le problème ou de rechercher l'expertise de l'industrie. Demandez à des experts en technologie sur Twitter. Envoyez un courriel à votre fournisseur de technologie.

Robert Anton Reese
la source
79

Quitter. Non, pas ton boulot! Levez-vous et rentrez chez vous. Vous avez terminé pour la journée ou le week-end. 19 fois sur 20 lorsque vous reviendrez au problème, la solution se présentera dans l'heure.

Dave Nay
la source
17
Vous pouvez également essayer le caoutchouc pour l'éviter. en.wikipedia.org/wiki/Rubber_duck_debugging
Dave Nay
2
19 sur 20, oui. Mon pire n'a jamais été résolu, il a seulement fonctionné. Aucun environnement de test ne l'a jamais montré, seulement l'environnement de production complet en fonctionnement - nous ne pouvions même pas le reproduire après les heures.
Loren Pechtel
3
S'éloigner de quelque chose qui vous irrite peut être très difficile - mais j'ai trouvé au fil des ans que c'est toujours la meilleure chose à faire. L'esprit subconscient peut travailler sur le problème pendant que vous mangez, dormez bien, regardez la télévision ... et le lendemain (ou le lendemain), les choses vont mieux. Un mot d'avertissement cependant: recueillez des informations avant de vous éloigner ... S'éloigner n'est pas la même chose que de l'ignorer et de prétendre qu'elle n'est pas là. Vous avez encore besoin d'un travail acharné!
quick_now
1
Je ne sais pas environ une heure. Je règle généralement la plupart de ces types de problèmes sous la douche lorsque je me lève le matin. Le deuxième plus fréquent sera quand je suis presque endormi la nuit et que je me suis finalement permis d'arrêter d'y penser.
SoylentGray
3
Il y avait une fascinante NOVA Science NOW animée par Neil deGrasse Tyson qui a parlé de la science du sommeil. On y a discuté du phénomène de se cogner la tête sur un problème pendant des heures, de s'endormir, de se réveiller et de le résoudre immédiatement. Quand nous dormons, notre cerveau transforme les événements de notre journée encore et encore et encore, les analysant sous de nombreux angles différents. Ce qu'elle laisse derrière elle, ce sont de nouvelles voies neuronales qui peuvent réellement nous aider à voir le problème d'une toute nouvelle manière inconsciemment, puis à résoudre le problème. Plutot cool.
Byrne Reese
44

Avant dix heures, j'obtiendrais de l'aide.

  1. Décrivez le problème à quelqu'un d'autre, à quelqu'un d'autre, même à votre canard en caoutchouc .
  2. Demandez à quelqu'un d'autre de jeter un œil au code ou de le parcourir avec lui.
  3. Isolez-le. Supprimez un tas de choses, puis ramenez-le petit à petit jusqu'à ce que le problème réapparaisse.
  4. Dormir un peu!
Kevin Cline
la source
12
+1 pour tout supprimer jusqu'à disparition du problème.
Jonah
4
Vous devriez faire l'une de ces choses avant qu'une heure ne s'écoule. Plus vous regardez, moins vous avez de chances de réaliser votre révélation. Normalement, je résout un problème simplement en discutant avec quelqu'un.
Ben
Repérez. Souvent, je trouve le problème (ou je m'en approche) en décrivant d'abord le problème. Cela se produit fréquemment lors de l'écriture d'une description du problème pour une question StackOverflow. Ce qui nécessite également une réduction (isolement) et à défaut, une période d'attente où vous vous éloignez du problème et laissez les réponses SO entrer en jeu.
sholsinger
17

Un mot,, timeboxdéfinissez un temps limité pour travailler sur quelque chose, et si ce n'est pas résolu, passez à autre chose et revenez-y le lendemain avec une nouvelle perspective.

Cela et une autre paire d'yeux, vaut toujours plus que n'importe quel temps que vous pouvez perdre à regarder quelque chose.

Je ne passerais jamais plus de 45 minutes à une heure à essayer de résoudre quelque chose en une seule séance, cela viole la loi des rendements décroissants.

user7519
la source
Merci beaucoup - j'ai lu l'article de timebox sur wikipedia, très utile.
Adel
7

Expliquez le problème à quelqu'un d'autre.

En expliquant le problème à quelqu'un d'autre, vous devez le clarifier: cela vous permet souvent de voir la solution.

(L'un des magazines informatiques professionnels du Royaume-Uni a déjà proposé de vendre des découpes en carton grandeur nature d'un programmeur principal spécialement à cette fin.)

Je trouve que dormir sur un problème (parfois pendant quelques jours) peut également aider.

MZB
la source
1
"Quelqu'un d'autre" n'a pas besoin d'être humain. Parfois j'explique des choses au chat, et aha! Je trouve le problème.
DarenW
Je devrais vraiment aussi acheter un chat. Je l'entraînerais à me gratter la tête sur demande.
Adel
Quelqu'un devrait vraiment faire une découpe en carton grandeur nature de Jon Skeet.
Don Roby
5

J'ai un plan en trois étapes:

  1. Obtenez un café ou une autre boisson savoureuse.
  2. Travaillez sur autre chose pour le reste de la journée.
  3. "Téléphonez à un ami" et griffonnez sur le tableau blanc.

Chaque étape est une escalade si l'étape précédente a échoué. Il y a presque toujours quelque chose d'autre productif sur lequel je peux travailler à l'étape 2.

Flexo
la source
Bon conseil! Donc "Téléphonez à un ami" est cité car il devrait être limité à 60 secondes, comme sur Millionaire, ouais? J'aime aussi l'idée du tableau blanc.
Adel
1
Je trouve que le tableau blanc aide vraiment à y réfléchir méthodiquement. Les citations étaient parce que souvent l'ami est dans le même bureau, donc appeler serait bizarre. Mais cela ressemblait à une bouée de sauvetage de l'émission de télévision.
Flexo
4

Dors dessus

Sinon, appelez quelqu'un à proximité et demandez-lui de jeter un coup d'œil au code.

Souvent, les erreurs qui vous mettraient longtemps à trouver (puisque c'est votre code) sont trouvées très facilement par d'autres

Akash
la source
3

Vous pouvez voir si vous lever, faire les cent pas et réfléchir au problème vous aide à trouver une solution. Que vous soyez ou non debout ou en train de marcher, essayez de vous éloigner de l'ordinateur pendant que vous réfléchissez.

compman
la source
3

Je fais généralement l'un des trois:

  1. Faites une promenade à pied / à vélo ... certains qui vous éloignent de l'ordinateur.
  2. Joue avec mon chien ou mon chat
  3. Si vous avez un passe-temps, travaillez-le pendant un certain temps.

Chacun des trois réussit à se distraire de la situation actuelle. Je trouve que les distractions laissent mon cerveau subconscient mâcher quelque chose pendant un moment. Après environ une heure, bam, il y a la solution :-).

toddward
la source
3

Construisez un faisceau de test pour cibler ce défaut exact et isolez-le

Continuez simplement à éliminer le bon code .. tout en reproduisant le défaut. Jusqu'à ce que vous cibliez le morceau de code exact contenant l'erreur. Tracez ensuite le code.

Lecture recommandée: Le programmeur pragmatique en particulier Chapitre 10: Balles de traçage

Morons
la source
tout cela est bien et bien mais il va de soi que le bug a été et peut être reproduit. Que se passerait-il si les 19 heures passées jusqu'à présent étaient exactement cela ... essayer de trouver un moyen de reproduire le problème de manière déterministe et systématique ... et alors? Pour moi, c'est l'essence de la question ici!
Newtopian
Le programmeur pragmatique est excellent
Adel
2

Toutes ces suggestions sont excellentes. Cependant, j'utilise assez souvent une technique que je n'ai pas vue mentionnée. Faites des listes pour organiser vos réflexions sur le problème. Si j'ai un problème particulièrement délicat, j'écris généralement plusieurs listes telles que: faits, hypothèses, questions, symptômes, etc. Je trouve que souvent dans le processus d'organisation des choses de cette manière, je découvre des hypothèses que je ne savais pas que j'avais ( qui se révèlent souvent faux), des questions que je ne comprenais pas doivent être posées, d'autres permutations que je peux vérifier, etc.

RationalGeek
la source
2

Modifier:

La réponse courte:

Q: Comment abordez-vous les erreurs vraiment bizarres qui vous laissent perplexe pendant plus de 10 heures?

R: Assurez-vous qu'ils ne se produisent jamais: comprenez votre conception, connaissez votre code, apprenez à utiliser votre débogueur.


Explication:

"Là où il semble qu'un gremlin vient de sauter au plus profond de vos jetons et de gâcher quelque chose"

Cela ne devrait jamais arriver. Si c'est votre code, vous devriez avoir une très bonne idée de la cause de l'erreur avant de tenter de la corriger.

De plus, lorsque vous écrivez votre code, vous devez déjà savoir où et pourquoi il est susceptible d'échouer.

Cela dit - demander à un pair, publier sur SO, revenir sur vos pas et revenir en arrière et faire une pause - toutes les suggestions mentionnées ci-dessus vous aideront.

L'autre chose, c'est que vous devez connaître vos outils - votre boîte à outils de débogage. Journalisation des messages à des points suspects dans votre code, examen attentif de votre pile d'appels, utilisation de points d'arrêt conditionnels et de surveillance, etc. Les compétences de débogage ne sont pas des extras - elles font partie de la programmation.

Mikey
la source
Être capable de revenir sur ses pas est vital. Merci!
Adel
> Être capable de revenir sur ses pas est vital. Le logiciel SourceControl est la clé pour pouvoir annuler / retracer. Soyez ANAL à ce sujet et si vous le pouvez, définissez vos paramètres pour vous forcer à laisser des commentaires lors de l'enregistrement.
Vecteur
3
Malheureusement, quelle que soit votre connaissance du code, le problème est parfois une interaction avec le code (source fermée) de quelqu'un d'autre.
Nate CK
2
+1 @Nate CK- très vrai. Les pires types de bogues se produisent lorsque vous récupérez une sorte de charabia d'un service Web sur lequel vous comptiez. J'ai eu un fournisseur Saas il y a quelque temps qui a subtilement changé certaines fonctionnalités sans avertissement dans leur service Web. J'ai dû expliquer au développeur comment résoudre son propre bug par téléphone alors qu'il me décrivait à quoi ressemblait son code.
Morgan Herlocker
1
Pour déterminer quoi? Qu'il y a un problème dans le code tiers? Cette partie est relativement facile. La partie difficile consiste à déterminer les conditions qui le déclenchent et comment contourner ce problème.Lorsque vous n'avez pas la source, le fournisseur n'est pas réactif et peut-être que cela ne se produit pas sur votre système de test. Si vous pensez que connaître votre code va résoudre tout cela pour vous, je suggère que vous n'avez peut-être jamais eu à y faire face.
Nate CK
1

J'ai eu un problème similaire, une corruption de mémoire apparente dans Objective-C, avec laquelle j'ai lutté pendant de nombreuses heures. Mais ensuite, mes collègues et moi-même nous sommes juste promenés pour le déjeuner, et j'ai expliqué le problème (et un élément particulier lié à la désérialisation d'un objet dans sa méthode init), et je me suis expliqué le problème dans son ensemble.

(détails techniques: fondamentalement, j'ai initialisé et renvoyé un objet sur autre chose que soi, donc il y avait deux allocations, mais un seul objet est revenu. La mémoire a changé et est devenue folle, se bloque, et le débogueur ne savait pas vraiment quoi faire avec soit).

Cthulhu
la source
1
"J'ai initialisé et rendu un objet sur autre chose que moi" - des bugs comme ça sont DIFFICILE! Vous pouvez le regarder plus de 100 fois et ne pas l'attraper. Mais ne pouviez-vous pas voir deux allocations en traçant dans le débogueur?
Vecteur
1

entrez la description de l'image ici

Prendre un bain.

Des fans de Rodney McKay ?

Sérieusement, cependant, s'il y a un point commun entre toutes ces réponses, c'est de faire une pause et de faire autre chose .

J'aime à penser que cela relègue le problème à votre subconscient. Même si nous n'en sommes pas conscients, nos esprits (semblent) continuer à travailler sur le problème, même lorsque nous faisons autre chose, comme prendre un bain .

Bourrage papier
la source
Excellente idée ... maintenant, je dois juste demander au patron de mettre une demi-douzaine de baignoires dans le bureau.
Dave Nay
Si seulement la légion d'ouvriers avait chacun une pièce comme celle-là.
Adel
1

Parcourez-le étape par étape, jusqu'à l'assemblage. Qui appelle quoi, point d'arrêt sur l'accès à la mémoire. Cela détecte généralement le bug très rapidement.

Sinon, faites une promenade.

Codeur
la source
1

Une combinaison de tous ces éléments:

  • Éloignez- vous-en pendant un moment afin qu'il puisse s'asseoir sur votre brûleur arrière. Dormez, reposez-vous, mangez, promenez-vous, peu importe.

  • Examinez davantage le problème, que fait-il d'autre mal, quels autres symptômes pouvez-vous trouver?

  • Recherchez le problème, voyez ce que vous pouvez trouver. N'oubliez pas d'essayer différents mots clés

  • Essayez quelque chose de différent . Un travail autour. Une technique de débogage différente. Un validateur. Un ordinateur différent.

  • Parlez à quelqu'un . Même s'ils ne sont pas en mesure d'aider, ou même pas un programmeur, parler peut parfois déclencher l'idée de l'ampoule

  • Redémarrer! Le cas échéant, essayez de redémarrer votre ordinateur, le serveur, etc. Si rien d'autre, vous pouvez utiliser le temps pour réfléchir.

  • Demandez à StackOverflow! Nous sommes ici pour aider

rlb.usa
la source
1

Je n'ai vraiment pas aimé la réponse la plus votée, car même si cela fonctionne parfois, il suffit parfois de la comprendre le même jour, alors ce que je recommanderais, dans cet ordre, c'est:

  1. Confirmez que cela ne vous arrive pas seulement. Cela peut vous faire gagner beaucoup de temps. Vous avez peut-être désinstallé un composant requis ou apporté une modification à votre environnement, et une exception est en train d'être avalée quelque part dans votre code. Si cela ne vous concerne que, j'utiliserais un outil de comparaison d'environnement. J'ai récemment lu sur un logiciel appelé Envy, qui vous permet de faire exactement cela, bien qu'il ne s'agisse pas d'un logiciel gratuit, il coûte 10 USD.

  2. Ça arrive à tout le monde? Très bien, faites maintenant un historique de visualisation sur le code et vérifiez les changements récents qui pourraient avoir causé l'erreur, directement ou indirectement.

  3. Il n'y a pas de changements récents? S'il s'agit d'une erreur très spécifique (une exception), 'stackoverflow it'. Maintenant, cela ne sonne pas mieux que «google it», mais je me sens bien de dire que je recherche d'abord stackoverflow pour la recherche en programmation que google. S'il s'agit d'un problème vraiment connu, il est très probable que vous trouverez une solution ici. Sinon, postez une question sur le site stackexchange associé. Vous pourriez obtenir une réponse très rapide, ou même si vous ne le faites pas, votre question sera là pendant que vous effectuez plus de recherches. Voilà un avantage.

  4. Si vous n'avez pas trouvé de réponse en ligne ou que ce n'est pas une erreur générale, parcourez le code étape par étape, en vérifiant si les résultats obtenus de chaque étape ont un sens pour le résultat que vous attendez. Allez du début à la fin de chaque méthode, et de bas en haut sur une solution à plusieurs niveaux. (c.-à-d. si vous dépannez les performances, commencez par le code qui récupère les enregistrements. n'a pas de sens de commencer dans l'interface utilisateur si vous pouvez déterminer rapidement si la première étape est le problème).

  5. Si après avoir parcouru le code plusieurs fois, vous n'avez toujours pas trouvé ce qui ne va pas, appelez quelqu'un pour en parler. Comme quelqu'un l'a déjà mentionné, en parler à haute voix peut allumer l'ampoule. De plus, la programmation par paires est vraiment utile.

  6. À ce stade, si c'est possible, éloignez-vous pendant un certain temps ou pour la journée. Hier, j'ai lu un tweet très vrai qui disait "Je suis allé me ​​coucher en pensant" comment ça va "et je me suis réveillé en pensant" mais bien sûr "". Tellement vrai.

  7. Si vous n'avez toujours pas de réponse, j'ose dire que vous pouvez essayer de refactoriser en tâches / méthodes / fonctions plus petites. Henry Ford a dit quelque chose comme «Il n'y a pas une tâche si complexe qui ne peut être accomplie en la divisant en tâches plus petites». À ce stade, si la solution est trop complexe et que vous n'avez pas compris par vous-même ou avec l'aide de quelqu'un d'autre, refactorisez le code en tâches plus petites. Même si vous ne finissez pas par le commettre, cela peut vous aider à trouver la raison.

  8. Ajoutez une instrumentation à votre code.

  9. Tweetez à ce sujet ??

silverCORE
la source
1

Vous devez prendre du recul. Ma devise est «si le problème est trop difficile, vous résolvez le mauvais problème». Quelles sont vos hypothèses? ne fais confiance à rien.

Le corollaire à cela est «plus le problème est étrange, plus la solution est étrange». La force de l'ordinateur réside dans sa logique, vous ne pouvez donc pas gagner sur la logique. Vous avez un cerveau et devez le penser.

Dans les temps modernes, il y a tellement d'autres choses qui interagissent sur un système - pare-feu, AV, antispyware, mises à jour automatiques qui ont lieu tous les soirs - vous devez faire face à des cibles mobiles.

jqa
la source
Si vrai que «plus le problème est étrange, plus la solution est étrange»
Adel
-1

Recherche le sur Google. Stackoverflow it. Postez-le sur les forums. Fondamentalement, si vous ne pouvez pas le résoudre seul, demandez aux gens de vous aider.

Pacerier
la source
-1
  1. Notez le problème.
  2. Réfléchissez bien.
  3. Implémentez la solution.
Ingo
la source
Concis, très bon!
Adel
1
En fait non. Penser trop fort sur les mêmes pistes est à peu près la pire chose que vous puissiez faire. «Contester, énumérer, revoir et tester chacune de vos hypothèses, de manière systématique» est la solution ici; les gens discutent de différentes tactiques pour y parvenir.
smci