Nous avons un bug dans notre application, qui ne se produit pas à chaque fois et, par conséquent, nous ne savons pas sa "logique". Je n'ai même pas il reproduit en 100 fois aujourd'hui.
Avertissement: Ce bug existe et je l'ai vu. Ce n'est pas un pebkac ou quelque chose de similaire.
Ce sont communs conseils pour reproduire ce genre de bug?
Analyser le problème dans une paire et une paire de lire le code. Prendre des notes sur les problèmes que vous SAVEZ être vrai et essayer de faire valoir logique conditions doit être vraie pour que cela arrive. Suivre les éléments de preuve comme un CSI.
La plupart des gens instinctivement dire "ajouter plus de journalisation", et cela peut être une solution. Mais pour beaucoup de problèmes de ce fait juste empirer les choses, depuis l'enregistrement peuvent changer le timing dépendances suffisamment pour rendre le problème plus ou moins fréquentes. La modification de la fréquence de 1 sur 1000 à 1 pour 1 000 000 va pas vous apporter plus près de la véritable source du problème.
Donc, si votre raisonnement logique ne permet pas de résoudre le problème, il va probablement vous donner quelques détails vous pourriez étudier avec l'exploitation forestière ou des affirmations dans votre code.
Il n'existe pas de bonne réponse à la question, mais voici ce que j'ai trouvé:
Il faut du talent pour ce genre de chose. Tous les développeurs sont les mieux adaptés pour elle, même si ils sont des superstars dans d'autres domaines. Afin de connaître votre équipe, qui a un talent, et j'espère que vous pourrez leur donner assez de bonbons pour les obtenir excité au sujet de vous aider, même si ce n'est pas le leur.
Le travail à l'envers, et la traiter comme une enquête scientifique. Démarrer avec le bug, ce que vous voyez est faux. Faire des hypothèses sur ce qui a pu provoquer (c'est le créatif, imaginatif partie, l'art que le monde n'a pas le talent pour) - et qu'il aide beaucoup de savoir comment le code fonctionne. Pour chacune de ces hypothèses (de préférence triés par ce que vous pensez est le plus probable - de nouveau pur instinct ici), de développer un test qui tente d'éliminer la cause, et de tester l'hypothèse. Tout manquement à une prédiction ne signifie pas que l'hypothèse est fausse. Test de l'hypothèse jusqu'à ce qu'il est confirmé à tort (bien qu'il est moins probable que vous pouvez le déplacer sur une autre hypothèse tout d'abord, il suffit de ne pas oublier ce un seul jusqu'à ce que vous avez un échec définitif).
Recueillir autant de données que vous pouvez au cours de ce processus. Exploitation Extensive et tout ce qui est applicable. Ne négligez pas une hypothèse à cause du manque de données, au lieu de remédier au manque de données. Assez souvent la source d'inspiration pour le droit hypothèse provient de l'analyse des données. Remarquant quelque chose dans une trace de la pile, bizarre question dans un journal, il manque quelque chose qui devrait être là dans une base de données, etc.
Vérifiez chaque hypothèse. Tant de fois j'ai vu une question qui n'est pas corrigé rapidement parce que certains généraux de l'appel de méthode n'a pas été encore étudié, de sorte que le problème était juste supposé être pas applicable. "Oh, ça devrait être simple." (Voir point 1).
Si vous manquez d'hypothèses, qui est généralement causée par le manque de connaissance sur le système (ce qui est vrai même si vous avez écrit chaque ligne de code vous-même), et vous avez besoin de courir à travers et à l'examen de code et de mieux comprendre le système à venir avec une idée nouvelle.
Bien sûr, aucune de ces garanties n'importe quoi, mais c'est l'approche que j'ai trouvé obtient des résultats de manière cohérente.
Il est assez commun pour les programmeurs de ne pas être en mesure de réitérer un utilisateur expérimenté un crash tout simplement parce que vous avez développé un certain flux de travail et les habitudes dans l'utilisation de l'application qui a évidemment fait le tour de la bogue.
À cette fréquence de 1/100, je dirais que la première chose à faire est de gérer les exceptions et les journaux importe quoi n'importe où ou vous pourriez être de passer une semaine à la chasse de ce bug. Aussi faire une liste de priorité d'potentiellement sensibles articulations et les fonctionnalités de votre projet. Par exemple : 1 - le Multithreading 2 - Wild pointeurs/ lâche tableaux 3 - la Dépendance sur les périphériques d'entrée etc. Cela vous aidera à segmenter les zones que vous pouvez brute-force-jusqu'à la rupture de nouveau comme suggéré par d'autres affiches.
Depuis cette est indépendant de la langue, je vais vous parler de quelques axiomes de débogage.
Rien qu'un ordinateur n'est aléatoire. Un "fruit du hasard" indique un encore inconnues modèle. Débogage commence par isoler le motif. Varier les éléments individuels et d'évaluer ce qui en fait un changement dans le comportement de l'insecte.
Autre utilisateur, même ordinateur? Même utilisateur, ordinateur différent? La survenue fortement périodiques? Ne le redémarrage de modifier la périodicité?
FYI - j'ai vu une fois un bug qui a été vécu par une seule personne. Je veux dire littéralement que personne, pas un compte d'utilisateur. L'utilisateur A ne verrait jamais le problème de leur système, l'Utilisateur B asseyez-vous à ce poste de travail connecté en tant qu'Utilisateur d'Un et tout de suite pu reproduire le bug. Il devrait y avoir aucun moyen concevable pour l'application de connaître la différence entre le corps physique dans le fauteuil. Toutefois-
Les utilisateurs de l'application de différentes manières. L'utilisateur A habituellement utilisé un raccourci clavier pour invoquer une action et l'Utilisateur B a utilisé un écran de contrôle. La différence dans le comportement de l'utilisateur serait cascade dans une erreur visible quelques actions plus tard.
Une différence que les effets sur le comportement de la bogue devrait être étudiée, même si elle n'a pas de sens.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
