Il existe un certain nombre de définitions du mot science, mais il semble que vous vous référiez peut-être à ce que l'on pourrait appeler plus précisément la " méthode scientifique ". La méthode scientifique peut être résumée comme l'observation de certains phénomènes (vraisemblablement un bug ou un comportement de programme inattendu), la formulation d'une ou de plusieurs hypothèses pour expliquer le comportement, et l'expérimentation la plus probable pour le prouver (écrire un test qui reproduit le problème de manière fiable).
Les types de bugs (phénomènes) qui peuvent survenir sont pratiquement infinis et certains ne nécessitent pas nécessairement un processus bien défini. Par exemple, parfois vous observez un bogue et vous savez instantanément ce qui l'a causé simplement parce que vous êtes très familier avec le code. D'autres fois, vous savez qu'à partir d'une certaine entrée (action, série d'étapes, etc.), un résultat incorrect se produit (plantage, mauvaise sortie, etc.). Pour ces cas, cela ne nécessite souvent pas beaucoup de réflexion "scientifique". Une réflexion peut aider à réduire l'espace de recherche, mais une méthode courante consiste simplement à parcourir le code dans un débogueur et à voir où les choses ont mal tourné.
Cependant, les situations que je trouve les plus intéressantes et peut-être dignes d'un processus scientifique sont celles où l'on vous remet un résultat final et qu'on vous demande d'expliquer comment cela s'est produit. Un exemple évident de ceux-ci est un vidage sur incident. Vous pouvez charger le vidage sur incident et observer l'état du système et votre travail consiste à expliquer comment il est arrivé dans cet état. Le vidage sur incident (ou principal) peut afficher une exception, un blocage, une erreur interne ou un état "indésirable" tel que défini par l'utilisateur (par exemple, lenteur). Pour ces situations, je suis généralement suivre les étapes suivantes:
Observation étroite : Étudiez les informations entourant directement le problème spécifique, le cas échéant. Les choses évidentes ici sont la pile d'appels, les variables locales si vous pouvez les voir, les lignes de code entourant le problème. Ce type d'étude de localisation spécifique n'est pas toujours applicable. Par exemple, l'étude d'un système "lent" peut ne pas avoir un emplacement de départ évident comme celui-ci, mais une situation de crash ou d'erreur interne aura probablement un point d'intérêt immédiat et évident. Une étape spécifique ici pourrait être d'utiliser des outils tels que windbg (exécutez! Analyse -v sur un vidage sur incident chargé et regardez ce qu'il vous dit).
Large observation : étudiez d'autres parties du système. Examinez l'état de tous les threads du système, examinez toutes les informations globales (nombre d'utilisateurs / opérations / éléments, transactions / processus / widgets actifs, etc.), les informations du système (OS), etc. Si l'utilisateur a fourni des détails externes , pensez à ceux-ci en conjonction avec ce que vous avez observé. Par exemple, s'ils vous ont dit que le problème se produit tous les mardis après-midi, demandez-vous ce que cela pourrait signifier.
Hypothétiser: C'est la partie vraiment amusante (et je ne suis pas gênant que ce soit amusant). Cela nécessite souvent beaucoup de réflexion logique à l'envers. Il peut être très agréable de penser à la façon dont le système est entré dans son état actuel. Je soupçonne que c'est la partie que beaucoup de gens considèrent comme un art. Et je suppose que cela pourrait être si le programmeur commence simplement à lancer des choses au hasard pour voir ce qui colle. Mais avec l'expérience, cela peut être un processus assez bien défini. Si vous pensez très logiquement à ce stade, il est souvent possible de définir des ensembles possibles de chemins qui ont conduit à l'état donné. Je sais que nous sommes dans l'état S5. Pour que cela se produise, S4a ou S4b devait se produire et peut-être S3 avant S4a, etc. Le plus souvent, il peut y avoir plusieurs éléments qui pourraient conduire à un état donné. Parfois, il peut être utile d'écrire sur un bloc-notes un simple diagramme de flux ou d'état ou une série d'étapes liées au temps. Les processus réels ici varieront considérablement en fonction de la situation, mais une réflexion sérieuse (et un réexamen dans les étapes précédentes) à ce stade fournira souvent une ou plusieurs réponses plausibles. Notez également qu'une partie extrêmement importante de cette étape consiste à éliminer les choses impossibles. Supprimer l'impossible peut aider à réduire l'espace de la solution (rappelez-vous ce que Sherlock Holmes a dit sur ce qui reste après avoir éliminé l'impossible). Notez également qu'une partie extrêmement importante de cette étape consiste à éliminer les choses impossibles. Supprimer l'impossible peut aider à réduire l'espace de la solution (rappelez-vous ce que Sherlock Holmes a dit sur ce qui reste après avoir éliminé l'impossible). Notez également qu'une partie extrêmement importante de cette étape consiste à éliminer les choses impossibles. Supprimer l'impossible peut aider à réduire l'espace de la solution (rappelez-vous ce que Sherlock Holmes a dit sur ce qui reste après avoir éliminé l'impossible).
Expérience : Dans cette étape, essayez de reproduire le problème sur la base des hypothèses dérivées à l'étape précédente. Si vous avez réfléchi sérieusement à l'étape précédente, cela devrait être très simple. Parfois, je "triche" et modifie la base de code pour aider un test donné. Par exemple, j'ai récemment enquêté sur un accident dont j'ai conclu qu'il s'agissait d'une condition de course. Afin de le vérifier, j'ai simplement mis un Sleep (500) entre quelques lignes de code pour permettre à un autre thread de faire ses mauvaises choses au "bon" moment. Je ne sais pas si cela est autorisé dans la "vraie" science, mais c'est parfaitement raisonnable dans le code que vous possédez.
Si vous réussissez à le reproduire, il est probable que vous ayez presque terminé (il ne vous reste plus qu'à la réparer ... mais c'est pour un autre jour). Assurez-vous de vérifier le nouveau test dans le système de test de régression. Et je dois souligner que je voulais que cette déclaration précédente sur le fait qu'il soit simple d'être ironique. La recherche d'une solution et sa mise en œuvre peuvent nécessiter un travail important. Je pense que la correction d'un bogue ne fait pas partie du processus de débogage mais est plutôt du développement. Et si le correctif est impliqué, cela devrait nécessiter une certaine conception et une révision.