Est-il raisonnable d'insister pour reproduire chaque défaut avant de le diagnostiquer et de le réparer?
Je travaille pour une société de produits logiciels. Nous avons des clients de grandes entreprises qui mettent en œuvre notre produit et nous les accompagnons. Par exemple, s'il y a un défaut, nous fournissons des correctifs, etc. En d'autres termes, c'est une configuration assez typique.
Récemment, un ticket a été émis et attribué à moi concernant une exception trouvée par un client dans un fichier journal qui a à voir avec l'accès simultané à la base de données dans une implémentation en cluster de notre produit. La configuration spécifique de ce client peut donc être critique dans l'occurrence de ce bogue. Tout ce que nous avons reçu du client était son fichier journal.
L'approche que j'ai proposée à mon équipe était de tenter de reproduire le bug dans une configuration similaire à celle du client et d'obtenir un journal comparable. Cependant, ils ne sont pas d'accord avec mon approche en disant que je n'ai pas besoin de reproduire le bogue car il prend trop de temps et nécessitera de simuler un cluster de serveurs sur des machines virtuelles. Mon équipe suggère simplement de "suivre le code" pour voir où se trouve le code non sécurisé pour les threads et/ou les transactions et de mettre en œuvre le changement à partir d'un simple développement local, qui n'est pas une implémentation de cluster comme l'environnement à partir duquel l'occurrence du bogue provient.
Pour moi, travailler à partir d'un modèle abstrait (code de programme) plutôt que d'une manifestation tangible et visible (reproduction à l'exécution) semble difficile, alors je voulais poser une question générale:
Est-il raisonnable d'insister pour reproduire chaque défaut et le déboguer avant de le diagnostiquer et de le réparer?
Ou:
Si je suis un développeur senior, dois-je être en mesure de lire du code multithread et de créer une image mentale de ce qu'il fait dans tous les scénarios de cas d'utilisation plutôt que d'exiger d'exécuter l'application, de tester différents scénarios de cas d'utilisation et de parcourir code ligne par ligne? Ou suis-je un mauvais développeur pour avoir exigé ce genre d'environnement de travail?
Le débogage pour les poules mouillées?
À mon avis, tout correctif soumis en réponse à un ticket d'incident doit être testé dans un environnement simulé pour être aussi proche que possible de l'environnement d'origine. Sinon, comment pouvez-vous savoir que cela résoudra vraiment le problème? C'est comme sortir un nouveau modèle de véhicule sans le tester avec un mannequin pour démontrer que les airbags fonctionnent bien.
Enfin et surtout, si vous êtes d'accord avec moi:
Comment dois-je parler avec mon équipe pour les convaincre que mon approche est raisonnable, conservatrice et plus à l'épreuve des balles?
Est-il raisonnable d'insister pour reproduire chaque défaut et le déboguer avant de le diagnostiquer et de le réparer?
Vous devriez faire de votre mieux. Je sais que parfois il y a des conditions et des environnements si complexes qu'ils ne peuvent pas être reproduits exactement , mais vous devriez certainement essayer si vous le pouvez.
Si vous n'avez jamais reproduit le bogue et l'avez vu par vous-même, comment pouvez-vous être sûr à 100% que vous l'avez vraiment corrigé? Peut-être que le correctif proposé introduit un autre bug subtil qui ne se manifestera que si vous essayez de reproduire le défaut d'origine.
Si je suis un développeur senior, devrais-je être capable de lire du code (multithread) et de créer une image mentale de ce qu'il fait dans tous les scénarios de cas d'utilisation plutôt que d'exiger d'exécuter l'application, de tester différents scénarios de cas d'utilisation et de parcourir le code ligne par ligne? Ou suis-je un mauvais développeur pour avoir exigé ce genre d'environnement de travail? Le débogage pour les poules mouillées?
Je ne ferais pas confiance à quelqu'un qui exécute le code "dans leur tête", si c'est leur approche uniquement . C'est un bon endroit pour commencer . Reproduire le bogue, le corriger et ensuite démontrer que la solution empêche le bogue de se reproduire - c'est là qu'il devrait se terminer .
Comment dois-je parler avec mon équipe pour les convaincre que mon approche est raisonnable, conservatrice et plus à l'épreuve des balles?
Parce que s'ils n'ont jamais reproduit le bogue, ils ne peuvent pas savoir avec certitude qu'il est corrigé. Et si le client revient et se plaint que le bug est toujours là, c'est pas une bonne chose. Après tout, ils vous paient gros (je suppose) pour faire face à ce problème.
Si vous échouez à résoudre correctement le problème, vous avez rompu la confiance du client (dans une certaine mesure) et s'il y a des concurrents sur votre marché, ils peut ne pas rester votre client.
Comment ont-ils l'intention de vérifier que le bogue en question a été corrigé? Souhaitent-ils envoyer du code non testé à l'utilisateur et le laisser le comprendre? Toute configuration de test qui n'a jamais été montrée pour reproduire l'erreur ne peut pas être invoquée pour montrer l'absence de l'erreur. Vous n'avez certainement pas besoin de reproduire tout l'environnement client, mais vous en avez besoin de suffisamment pour reproduire l'erreur.
Je ne pense pas qu'il soit déraisonnable d'essayer de reproduire chaque bogue avant de le corriger. Cependant, si vous essayez de le reproduire et que vous ne pouvez pas, cela devient une décision commerciale de savoir si les correctifs aveugles sont une bonne idée.
Idéalement, vous voulez être en mesure de reproduire chaque bogue afin que vous puissiez au moins tester qu'il a été corrigé.
Mais ... Ce n'est peut-être pas toujours faisable ni même physiquement possible. Surtout avec les logiciels de type "entreprise" où chaque installation est unique. Il y a aussi l'évaluation coûts/avantages. Quelques heures pour examiner le code et faire quelques suppositions éclairées sur un problème non critique peuvent coûter beaucoup moins cher que de passer des semaines à une équipe de support technique à essayer de configurer et de dupliquer l'environnement d'un client exactement dans l'espoir de pouvoir dupliquer le problème. À l'époque où je travaillais dans le monde `` Entreprise '', nous sortions souvent des codeurs et leur faisions corriger des bugs sur place, car il n'y avait aucun moyen de dupliquer la configuration du client.
Donc, dupliquez quand vous le pouvez, mais si vous ne le pouvez pas, exploitez vos connaissances du système et essayez d'identifier le coupable dans le code.
Je ne pense pas que vous devriez faire d'une reproduction de l'erreur une exigence pour regarder le bogue. Il y a, comme vous l'avez mentionné, plusieurs façons de déboguer le problème - et vous devez les utiliser toutes. Vous devriez vous compter chanceux d'avoir pu vous donner un fichier journal! Si vous ou quelqu'un de votre entreprise pouvez reproduire le bogue, tant mieux! Sinon, vous devez toujours essayer d'analyser les journaux et rechercher les circonstances dans lesquelles l'erreur s'est produite. Il est possible, comme vos collègues l'ont suggéré, de lire le code, de déterminer les conditions dans lesquelles le bogue pourrait se produire, puis d'essayer de recréer le scénario vous-même.
Cependant, ne publiez pas le correctif réel non testé. Toute modification que vous apportez doit passer par la routine standard de développement, de test d'AQ et de test d'intégration. Il peut s'avérer difficile à tester - vous avez mentionné le code multithread, qui est notoirement difficile à déboguer. C'est là que je suis d'accord avec votre approche pour créer une configuration ou un environnement de test. Si vous avez trouvé un problème dans le code, vous devriez trouver beaucoup plus simple de créer l'environnement, de reproduire le problème et de tester le correctif.
Pour moi, il s'agit moins d'un problème de débogage que d'un problème de service client. Vous avez reçu un rapport de bogue d'un client; vous avez la responsabilité de faire preuve de diligence raisonnable pour trouver leur problème et le résoudre.
À mon avis ... en tant que décideur, vous devez pouvoir justifier votre position. Si l'objectif du département de support de 3e ligne est de corriger les bogues dans les plus brefs délais avec l'effort acceptable du client, alors toute approche doit se conformer à cet objectif. De plus, s'il est prouvé que l'approche donne les résultats escomptés les plus rapides, il ne devrait y avoir aucun problème à convaincre l'équipe.
Ayant travaillé dans le support, je me suis toujours attendu à ce que le client soit en mesure de donner un "script" des actions qu'il a effectuées pour reproduire systématiquement le bogue et sinon des exemples candidats qui ont produit le bogue.
Si j'étais nouveau dans le système et que je n'avais aucune expérience avec le code, mes premières étapes seraient d'essayer d'identifier les sources possibles de l'erreur. Il se peut que la journalisation soit insuffisante pour identifier un code candidat. Selon le client, je pourrais être enclin à leur donner une version de débogage afin qu'ils puissent vous rendre des fichiers journaux qui donnent des indices supplémentaires sur la position du code incriminé.
Si je peux identifier rapidement le bloc de code, une cartographie visuelle du flux peut suffire à repérer le code. Sinon, une simulation basée sur des tests unitaires peut suffire. Il se peut que la configuration d'un environnement de réplication client prenne moins de temps, surtout s'il existe une grande reproductibilité du problème.
Je pense que vous trouverez peut-être que votre approche devrait être une combinaison des solutions proposées et que savoir quand en quitter une et passer à la suivante est la clé pour faire le travail efficacement.
Je suis tout à fait sûr que l'équipe soutiendra l'idée que s'il y a une chance que leur solution trouve le bogue plus rapidement, puis en leur donnant un délai approprié pour prouver que cela n'aura pas trop d'impact sur le temps qu'il faut pour corriger le bogue, selon le cas. l'itinéraire que vous prenez.
Est-il raisonnable d'insister pour reproduire chaque défaut et le déboguer avant de le diagnostiquer et de le réparer?
Je dis oui, avec quelques mises en garde.
- Je pense que c'est correct de lire le code et d'essayer de trouver des endroits qui semblent problématiques. Créez un correctif et envoyez-le au client pour voir si cela résout le problème. Si cette approche continue d'échouer, vous devrez peut-être rechercher d'autres options. N'oubliez pas que même si vous corrigez le bogue a, il se peut que ce ne soit pas le bogue signalé.
- Si vous ne pouvez pas le reproduire dans des limites raisonnables et que vous ne trouvez aucun indicateur rouge dans le code, cela peut nécessiter une coordination plus étroite avec le client. Je me suis rendu sur les sites des clients avant de faire le débogage sur site. Ce n'est pas le meilleur environnement de développement, mais parfois, si le problème est environnemental, trouver la cause exacte sera plus facile lorsque vous pourrez le reproduire de manière cohérente.
J'ai été du côté client de la table dans ce scénario. Je travaillais dans un bureau du gouvernement américain qui utilisait un cluster de base de données Oracle incroyablement grand (plusieurs téraoctets de données et traitant des millions d'enregistrements par jour).
Nous avons rencontré un problème étrange qui était très facile à reproduire. Nous avons signalé le bogue à Oracle, et nous sommes allés et venir avec eux pendant des semaines, en leur envoyant des journaux. Ils ont dit qu'ils n'étaient pas en mesure de reproduire le problème, mais ils nous ont envoyé quelques correctifs qui pourraient espérer résoudre le problème. Aucun d'eux ne l'a fait.
Ils ont finalement envoyé quelques développeurs chez nous pour déboguer le problème sur place. Et c'est à ce moment que la cause première du bogue a été trouvée et qu'un correctif ultérieur a correctement corrigé le problème.
Si vous n'êtes pas positif sur le problème, vous ne pouvez pas être positif sur la solution. Savoir reproduire le problème de manière fiable dans au moins une situation de cas de test vous permet de prouver que vous savez comment provoquer l'erreur, et vous permet donc également de prouver d'un autre côté que le problème a été résolu, en raison de l'absence subséquente d'erreur dans le même cas de test après avoir appliqué le correctif.
Cela dit, les conditions de concurrence, les problèmes de concurrence et d'autres bogues "non déterministes" sont parmi les plus difficiles à cerner par un développeur de cette manière, car ils se produisent rarement, sur un système avec une charge plus élevée et plus de complexité que n'importe quelle copie d'un développeur de le programme et ils disparaissent lorsque la tâche est réexécutée sur le même système à une date ultérieure.
Le plus souvent, ce qui ressemble à l'origine à un bogue aléatoire finit par avoir une cause déterministe qui se traduit par une reproductibilité déterministe une fois que vous savez comment. Ceux qui défient cela, les vrais Heisenbugs (des bugs apparemment aléatoires qui disparaissent lorsque vous tentez de les tester dans un environnement stérile et surveillé), sont liés au timing à 99,9%, et une fois que vous comprenez cela, votre voie à suivre devient plus claire; recherchez les choses qui pourraient échouer si quelque chose d'autre devait obtenir un mot dans le sens de la bordure pendant l'exécution du code, et lorsque vous trouvez une telle vulnérabilité, essayez de l'exploiter dans un test pour voir s'il présente le comportement que vous essayez de reproduire.
Une quantité importante d'inspection approfondie du code est généralement requise dans ces situations; vous devez regarder le code, abandonner toute notion préconçue de la façon dont le code doit supposé se comporter, et imaginer des scénarios dans lesquels il pourrait échouer de la manière dont votre client l'a observé . Pour chaque scénario, essayez de développer un test qui pourrait être exécuté efficacement dans votre environnement de test automatisé actuel (c'est-à-dire sans avoir besoin d'une nouvelle pile VM juste pour ce test)), qui prouverait ou prouver que le code se comporte comme prévu (ce qui, selon ce que vous attendiez, prouverait ou réfuterait que ce code est une cause possible des problèmes des clients) .C'est la méthode scientifique pour les ingénieurs logiciels; observez, émettez des hypothèses, testez, réfléchir, répéter.
Est-il raisonnable d'insister pour reproduire chaque défaut et le déboguer avant de le diagnostiquer et de le réparer?
Non, ce n'est vraiment pas le cas. Ce serait une politique stupide.
Le problème que je vois avec votre question et votre proposition est qu’ils ne font pas de distinction entre
- rapports de bogues
- échecs ( erreurs )
- bugs (parfois aussi appelés erreurs )
Un rapport de bogue est une communication sur un bogue. Cela vous dit que quelqu'un pense que quelque chose ne va pas. Il peut ou non être précis sur ce qui est censé être faux.
Un rapport de bogue est la preuve d'un échec.
Une défaillance est un incident de quelque chose qui ne va pas. Un dysfonctionnement spécifique, mais pas nécessairement avec des indices sur ce qui peut l'avoir causé.
Un échec peut être provoqué par un bogue.
Un bogue est une cause d'échecs; quelque chose qui peut (en principe) être modifié afin d'éviter que les défaillances qu'il provoque ne se reproduisent à l'avenir.
Parfois, lorsqu'un bug est signalé, la cause est immédiatement claire. Dans un tel cas, la reproduction du bogue serait absurde. À d'autres moments, la cause n'est pas claire du tout: le rapport de bogue ne décrit pas d'échec particulier, ou il le fait, mais l'échec est tel qu'il ne fournit aucun indice sur ce qui pourrait être la cause. Dans de tels cas, je pense que votre conseil est justifié - mais pas toujours: on n'insiste pas pour planter une deuxième fusée spatiale de 370 millions de dollars avant d'accepter d'enquêter ce qui a provoqué le crash de la première (un bug particulier dans le logiciel de contrôle).
Et il y a aussi toutes sortes de cas entre les deux; par exemple, si un rapport de bogue ne prouve pas, mais suggère seulement, qu'un problème potentiel que vous connaissiez déjà pourrait jouer un rôle, cela pourrait être une incitation suffisante pour que vous puissiez l'examiner de plus près.
Ainsi, bien qu'il soit judicieux d'insister sur la reproductibilité pour les cas les plus difficiles, il n'est pas judicieux de la faire respecter en tant que politique stricte.
Prenons-le à l'extrême et supposons que vous avez trouvé le bogue beaucoup plus tôt: dans votre code, tel que vous l'écriviez. Alors vous n'auriez aucun scrupule à le corriger juste là - vous voir une faille logique dans le code que vous venez d'écrire, il ne fait pas ce que vous vouliez qu'il fasse. Vous ne ressentiriez pas le besoin de configurer un environnement entier pour montrer qu'il s'agit en fait d'un bogue.
Maintenant, un rapport de bogue arrive. Il y a plusieurs choses que vous pouvez faire. L'un d'eux est de revenir au code et de le relire. Supposons maintenant que lors de cette deuxième lecture, vous trouviez immédiatement le bogue dans le code - il ne fait tout simplement pas ce que vous vouliez qu'il fasse, et vous n'avez pas remarqué quand vous l'avez écrit. Et, cela explique parfaitement le bug qui vient d'arriver! Vous faites le correctif. Ça vous a pris vingt minutes.
Est-ce que cela a corrigé le bogue à l'origine du rapport de bogue? Vous ne pouvez pas être sûr à 100% (il peut y avoir eu deux bugs provoquant la même chose), mais c'est probablement le cas.
Une autre chose que vous pourriez faire est de reproduire la configuration du client aussi bien que vous le pouvez (quelques jours de travail), et éventuellement de reproduire le bogue. Dans de nombreux cas, il y a des problèmes de synchronisation et de simultanéité qui signifient que vous ne pouvez pas reproduire le bogue, mais vous pouvez essayer beaucoup de temps et parfois voir la même chose se produire. Maintenant, vous commencez le débogage, trouvez l'erreur dans le code, mettez-la dans l'environnement et réessayez plusieurs fois. Vous ne voyez plus le bug se produire.
Est-ce que cela a corrigé le bogue à l'origine du rapport de bogue? Vous ne pouvez toujours pas être sûr à 100% - un, vous avez peut-être réellement vu un bogue complètement différent que le client a fait, deux, peut-être que vous n'avez pas essayé assez souvent, et trois, peut-être que la configuration est encore légèrement différente et c'est fixé sur ce système, mais pas celui du client.
La certitude est donc impossible à obtenir de toute façon. Mais la première méthode est beaucoup plus rapide (vous pouvez également donner au client un patch plus rapidement), est beaucoup moins cher et, si vous trouvez un bug de codage clair qui explique le symptôme, est en fait plus susceptible de trouver le problème aussi.
Cela dépend donc. S'il est bon marché de configurer un environnement de test (ou mieux: un test automatisé qui montre le problème), faites-le. Mais si cela coûte cher et/ou si les circonstances dans lesquelles le bogue apparaît sont imprévisibles, il est toujours préférable d'essayer de trouver le bogue en lisant d'abord le code.
À moins que l'erreur ne soit évidente, évidente et triviale, avec un message d'erreur très spécifique, etc., il est souvent très difficile de corriger un bogue si l'utilisateur ou le responsable n'est pas en mesure de le reproduire.
Comment pourriez-vous leur prouver que le bogue est corrigé si vous ne pouvez pas répliquer les étapes?
Le problème avec votre cas est que l'utilisateur ne sait pas non plus comment l'erreur s'est produite, c'est-à-dire dans quel écran de faire quelle opération. Ils ont simplement le journal.
Je pense que votre argument est raisonnable. Si vous avait des pouvoirs psychiques, vous ne travailleriez probablement pas pour un salaire.
Je pense que vous devriez dire à vos patrons que sans pouvoir reproduire l'erreur, il faudrait n temps inconn pour le découvrir, et il y a aucune garantie du tout que vous volonté.
Le problème sera quand un de vos collègues trouvera le bug par pure chance et le corrigera.
Comme pour tout le reste dans le développement de logiciels, la bonne réponse est un compromis.
En théorie, vous ne devriez jamais essayer de corriger un bogue si vous ne pouvez pas prouver qu'il existe. Cela peut vous amener à apporter des modifications inutiles à votre code qui ne résoudront finalement rien. Et le prouver, c'est d'abord le reproduire, puis créer et appliquer un correctif, puis démontrer qu'il ne se produit plus. Votre instinct ici vous guide dans la bonne direction - si vous voulez être sûr d'avoir résolu le problème de votre client, vous devez d'abord savoir ce qui l'a causé.
En pratique, ce n'est pas toujours possible. Peut-être que le bogue ne se produit que sur de grands clusters avec des dizaines d'utilisateurs accédant simultanément à votre code. Il existe peut-être une combinaison spécifique d'opérations de données sur des ensembles de données spécifiques qui déclenche le bogue et vous n'avez aucune idée de ce que c'est. Peut-être que votre client a exécuté le programme de manière interactive sans interruption pendant des centaines d'heures avant que le bogue ne se manifeste.
Dans tous ces cas, il y a de fortes chances que votre service n'ait pas le temps ou l'argent pour reproduire le bogue avant de commencer à travailler. Dans de nombreux cas, il est beaucoup plus évident pour vous, le développeur, qu'il y a un bogue dans le code qui vous indique la bonne situation. Une fois le problème diagnostiqué, vous pourrez peut-être revenir en arrière et le reproduire. Ce n'est pas idéal, mais en même temps, une partie de votre travail en tant que développeur principal consiste à savoir lire et interpréter le code, en partie pour localiser ce type de bogues enfouis.
À mon avis, vous vous concentrez sur la mauvaise partie de la question. Et si vous ne pouvez pas reproduire le bogue en question? Rien n'est plus frustrant pour un client que d'entendre "oui, nous savons que vous avez planté le programme mais nous ne pouvons pas le reproduire, donc ce n'est pas un bug." Lorsque votre client entend cela, il l'interprète comme "nous savons que notre logiciel est bogué, mais nous ne pouvons pas prendre la peine de corriger et de corriger les bogues, alors croisez simplement les doigts." S'il vaut mieux fermer un bogue signalé comme "non reproductible", ou le fermer comme "non reproductible, mais nous avons apporté quelques modifications raisonnables pour essayer d'améliorer la stabilité"?
Il me semble que vous avez besoin d'une journalisation plus détaillée.
Bien que l'ajout de journalisation ne puisse garantir que vous n'aurez pas besoin de déboguer (ou, dans ce cas, de reproduire la situation), cela vous donnera une bien meilleure idée de ce qui s'est réellement passé.
Surtout dans les situations compliquées/de threading, ou tout ce qui ne peut pas utiliser un débogueur, se rabattre sur "debug by printf ()" pourrait être votre seul recours. Dans ce cas, connectez-vous autant que vous le pouvez (plus que vous n'en attendez) et ayez de bons outils pour filtrer le blé de la balle.
Est-il raisonnable d'insister pour reproduire chaque défaut et le déboguer avant de le diagnostiquer et de le réparer?
Comme personne ne l'a encore dit clairement: Absolument pas!
Comme tout le reste dans le développement de logiciels, la correction de bogues signifie garder à l'esprit le temps, les risques et les coûts. Trouver un équilibre entre ceux-ci est la moitié de la description de travail d'un développeur.
Certains bogues ne sont pas assez importants pour passer 2 jours, mais assez importants pour passer 10 minutes à les corriger. D'autres bogues ne sont pas déterministes et vous savez déjà qu'un environnement de test ne peut pas prouver qu'ils ont été corrigés. Si la configuration de l'environnement de test prend 2 jours, vous ne le faites pas pour ces bogues. Au lieu de cela, vous passez du temps sur des choses plus intelligentes, telles que la recherche de moyens de configurer un environnement de test en 5 minutes au lieu de 2 jours.
Et bien sûr, il y a des bugs où si vous vous trompez, un client perdra 100 000 $ +. Et les bugs où le client perdra 100 000 $ + pour chaque heure où le bug n'est pas corrigé. Vous devez regarder le bug et prendre une décision. Les déclarations générales pour traiter tous les bogues de la même manière ne fonctionnent pas.
En lisant la question, je ne vois aucune opposition fondamentale entre votre position et celle de votre équipe.
Oui, vous devez faire de votre mieux pour reproduire le problème survenant dans le paramètre client. Mais le meilleur effort signifie que vous devez définir une zone de temps pour cela, et il peut ne pas y avoir suffisamment de données dans le journal pour reproduire réellement le problème.
Si oui, tout dépend de la relation avec ce client. Cela peut aller de vous, vous n'aurez rien d'autre de lui, à votre mai envoyer un développeur sur place avec des outils de diagnostic et la possibilité de les exécuter sur le système défaillant. Habituellement, nous sommes quelque part entre les deux et si les données initiales ne suffisent pas, il existe des moyens d'en obtenir davantage.
Oui, un développeur senior doit être capable de lire le code et est susceptible de trouver la raison du problème suite au contenu du journal. Vraiment, il est souvent possible d'écrire un test unitaire qui présente le problème après avoir lu attentivement le code.
Réussir à écrire de tels tests unitaires équivaut presque à reproduire l'environnement fonctionnel de rupture. Bien sûr, cette méthode n'est pas non plus une garantie que vous trouverez quelque chose. Comprendre la séquence exacte des événements conduisant à une défaillance dans certains logiciels multithread peut être très difficile à trouver en lisant simplement le code, et la capacité à déboguer en direct est susceptible de devenir critique.
En résumé, j'essaierais pour les deux approches simultanément et demanderais soit un système en direct présentant le problème (et montrant qu'il est résolu par la suite) soit un test de rupture unitaire brisant le problème (et montrant également qu'il est corrigé après la correction).
Essayer de corriger le code et de l'envoyer dans la nature semble en effet très risqué. Dans certains cas similaires qui m'ont été rencontrés (où nous n'avons pas réussi à reproduire le défaut en interne), j'ai précisé que si un correctif se déchaînait et ne résolvait pas le problème du client, ou avait d'autres conséquences négatives inattendues, le gars qui a proposé cela devrait aider l'équipe de support à trouver le problème réel. Y compris traiter avec le client si nécessaire.
Très bonne question! Mon avis est que si vous ne pouvez pas reproduire le problème, vous ne pouvez pas dire à 100% que le correctif que vous avez fait ne:
a) résoudre réellement le problème. b) créer un autre bug
Il y a des moments où un bogue se produit et je le corrige et je n'ai pas la peine de le tester. Je sais à 100% que cela fonctionne. Mais jusqu'à ce que notre service d'assurance qualité indique que cela fonctionne, je considère qu'il est toujours possible qu'un bogue soit toujours présent ... ou un nouveau bogue créé à partir du correctif.
Si vous ne pouvez pas reproduire le bogue, puis installez la nouvelle version et confirmez qu'il est corrigé, vous ne pouvez pas, avec une certitude à 100%, dire que le bogue a disparu.
J'ai essayé pendant quelques minutes de penser à une analogie pour vous aider à expliquer aux autres mais rien ne m'est vraiment venu à l'esprit. Une vasectomie est un exemple amusant mais ce n'est pas la même situation :-)
[bug lié à] accès simultané à la base de données, mise en œuvre en cluster, multithread
Est-il raisonnable d'insister pour reproduire chaque défaut et le déboguer avant de le diagnostiquer et de le réparer?
Je ne passerais pas trop de temps à essayer de le reproduire. Cela ressemble à un problème de synchronisation et ceux-ci sont plus souvent découverts par le raisonnement (à partir de journaux comme celui que vous devez identifier le sous-système dans lequel le problème se produit) que par la possibilité de trouver un moyen de le reproduire et de l'attaquer avec un débogueur . D'après mon expérience, réduire le niveau d'optimisation du code ou parfois et même activer une instrumentation supplémentaire peut être suffisant pour ajouter suffisamment de retard ou la primitive de synchronisation manquante pour empêcher le bogue de se manifester.
Oui, si vous n'avez pas de moyen de reproduire le bogue, vous ne pourrez pas être sûr de le corriger. Mais si votre client ne vous donne pas le moyen de le reproduire, vous pouvez également rechercher quelque chose de similaire avec la même conséquence mais une cause racine différente.
Les deux activités (révision et test du code) sont nécessaires, ni suffisantes.
Vous pourriez passer des mois à construire des expériences en essayant de reprocher le bogue, et ne jamais arriver nulle part si vous ne regardiez pas le code et formuliez une hypothèse pour réduire l'espace de recherche. Vous pourriez souffler des mois à regarder votre nombril en essayant de visualiser un bogue dans le code, vous pourriez même penser que vous l'avez trouvé une, deux, trois fois, seulement pour que le client de plus en plus impatient dise: "Non, le bogue est toujours là. "
Certains développeurs sont relativement meilleurs dans une activité (révision de code vs construction de tests) que dans l'autre. Un gestionnaire parfait pèse ces forces lors de l'attribution des bogues. Une approche d'équipe peut être encore plus fructueuse.
En fin de compte, il peut ne pas y avoir suffisamment d'informations pour reprocher le bogue, et vous devez le laisser mariner pendant un certain temps en espérant qu'un autre client trouvera un problème similaire, ce qui vous donnera plus d'informations sur le problème de configuration. Si le client qui a vu le bug veut vraiment qu'il soit corrigé, il travaillera avec vous pour collecter plus d'informations. Si ce problème n'est survenu qu'une seule fois, ce n'est probablement pas un bogue de haute priorité même si le client est important. Parfois, ne pas travailler un bogue est plus intelligent que de passer des heures-homme à chercher un défaut vraiment obscur avec pas assez d'informations.