Je travaille pour une entreprise de produits logiciels. Nous avons de grandes entreprises clientes qui mettent en œuvre notre produit et nous leur fournissons une assistance. Par exemple, s’il ya un défaut, nous fournissons des correctifs, etc. En d’autres termes, c’est une configuration assez typique.
Récemment, un ticket m'a été attribué et affecté concernant une exception trouvée par un client dans un fichier journal qui concerne l'accès simultané à une 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 la survenue de ce bogue. Le client ne nous a fourni que son fichier journal.
L’approche que j’ai proposée à mon équipe a été d’essayer de reproduire le bogue dans une configuration similaire à celle du client et d’obtenir un journal comparable. Cependant, ils sont en désaccord avec mon approche, affirmant que je n'ai pas besoin de reproduire le bogue, car il prend trop de temps et nécessite de simuler un cluster de serveurs sur des ordinateurs virtuels. Mon équipe suggère simplement de "suivre le code" pour voir où se trouve le code non sécurisé par 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 plan abstrait (code de programme) plutôt que d'une manifestation tangible et visible (reproduction à l'exécution) me 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 expérimenté, 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’exécuter l’application, de tester différents scénarios de cas d’utilisation et code ligne par ligne? Ou suis-je un mauvais développeur pour avoir exigé ce type d'environnement de travail?
Le débogage est-il pour les poules mouillées?
À mon avis, tout correctif soumis en réponse à un ticket d'incident doit être testé dans un environnement simulé aussi proche que possible de l'environnement d'origine. Sinon, comment pouvez-vous savoir que cela va vraiment résoudre le problème? C'est comme si on sortait un nouveau modèle de véhicule sans essai de collision avec un mannequin pour démontrer que les sacs gonflables fonctionnent réellement.
Last but not least, si vous êtes d'accord avec moi:
Comment parler à mon équipe pour la convaincre que mon approche est raisonnable, conservatrice et plus résistante aux balles?
new
. Et il n’est pas garanti que ces bogues soient reproductibles de manière fiable, conformément à la spécification du modèle de mémoire Java