Correction d'un bug qui n'a jamais causé de problème jusqu'à présent

J'ai récemment fait un changement qui a fait exécuter du code beaucoup plus souvent qu'auparavant. Cela a conduit à la découverte d'un bug. Ce bogue avait le potentiel de se produire à chaque fois que le code était exécuté, mais parce qu'il était si rarement exécuté, il n'a jamais fait surface.

Quand j'ai porté cela à l'attention du développeur principal, il voulait que j'annule le changement qui exposait le bogue plutôt que de corriger le bogue en citant l'adage, "Si ce n'est pas cassé, ne le corrige pas".

Il est clair pour moi que nous avons été chanceux jusqu'à présent, mais il n'écoutera pas la raison.

Dois-je le réparer de toute façon?

Mise à jour

Le lead n'a techniquement aucune autorité sur moi. Juste mandat. Il est le seul développeur du projet depuis un certain nombre d'années jusqu'à il y a un an et je pense qu'il n'accepte pas très bien les critiques constructives. Pour ce qui vaut, je ne l'ai pas critiqué. Je viens de souligner que le fait que le bogue ne soit jamais apparu ne voulait pas dire qu'il n'était pas là.

Je suggère que si vous avez un suivi des bogues, soumettez-le. Si c'est critique, élevez-le et portez-le à son attention. Laissez votre supérieur le rétrograder dans le tracker. Lorsque les choses tournent mal, vous aurez la trace papier.

Personnellement, je le réparerais, à moins que cela ne demande beaucoup plus d'efforts qu'il n'en valait la peine. "Si ce n'est pas cassé, ne le réparez pas" est horrible à appliquer au logiciel.

Si votre développeur principal est votre patron et qu'il dit de ne pas y toucher, dans ce cas, je ne le ferais pas.

La plupart des réponses et commentaires suggèrent d'atténuer la responsabilité de la décision en créant un rapport de bogue et en laissant quelqu'un d'autre passer l'appel.

Comme je n'ai pas de bug tracker (et je doute que quelqu'un d'autre que moi l'utilise si nous le faisions), j'ai fait la meilleure chose suivante. J'ai dépassé la tête du développeur principal. Après avoir expliqué la situation à la direction, ils ont vu les choses à ma façon. Ils m'ont dit de le réparer correctement et d'ignorer la demande de demande du lead . Ils ont dit qu'ils lisseraient toutes les plumes ébouriffées s'il découvrait le subterfuge et se plaignait.

Pas une solution idéale mais au moins le bug a été corrigé correctement.

Rappelez-lui que la phrase est «Si ce n'est pas cassé, ne le répare pas» et non «Si le client ne l'a pas remarqué, ne le répare pas».

Quelle justification avez-vous de la modification que vous avez apportée? Si vous ne pouvez pas indiquer les changements que l'utilisateur subirait ou la dette technique a été supprimée, je serais du côté du développeur principal en disant de simplement annuler le changement car cela ne fait qu'empirer les choses.

Vous avez au moins quelques options différentes ici à mon avis:

Si vous allez de l'avant et corrigez le bogue, vous risquez d'ajouter plus de bogues au mélange, ce qui pourrait me revenir à l'esprit. En fonction de votre expérience et de votre confiance pour éviter une mauvaise surprise, ce serait probablement mon guide ici.

Si vous faites ce qu'on vous a dit de faire, est-ce simplement la culpabilité qui serait le problème ou est-ce plus que cela? Je me demande ce qui ne va pas ici, à part ce truc connu sous le nom de principes et de valeurs. Je veux dire que c'est un peu une blague mais aussi un point honnête de ce qui ne va pas avec cette idée?

Alors que mon instinct écrasant serait de corriger les bugs pour ne pas cacher le problème, il y a des scénarios où je garderais mon nez et cacherais le problème.

1. Le code est utilisé en interne et occasionnellement, de sorte que les conséquences du bogue sont gérables à l'intérieur de l'entreprise.
2. Des considérations commerciales écrasantes qui exigeaient une livraison aujourd'hui, et une correction de bogue pourrait être déployée 2 semaines plus tard avec des conséquences minimes.

Professionnellement, je n'aime pas ces réponses, et je dirais clairement en interne que l'éther de ces situations se produisait.

En fin de compte, vous ne devriez rien faire que votre supérieur ait explicitement dit de ne pas faire. Je crois que la meilleure chose à faire dans votre position est de créer un rapport de bogue dans la base de données de suivi des bogues que vous possédez. de cette façon, au moins tout le monde est au courant du problème et quelqu'un avec plus d'autorité peut décider quoi en faire.

Copiez la fonction buggy, appliquez le correctif, renommez-le, déguisez-le peut-être un peu et appelez-le à la place.

Sur la base de vos deux commentaires sur les bugs showstopper, votre meilleur choix peut être de suivre la lettre de la loi, mais d'ignorer son esprit.

Évidemment, il y a un inconvénient au codage couper-coller, mais il semble que ce sera le moindre de vos problèmes.