Corriger des bugs ou attendre que le client les trouve?

Est-ce que d'autres personnes corrigent des bogues quand elles les voient ou attendent-elles jusqu'à ce qu'il y ait un crash / une perte de données / des personnes meurent avant de le réparer?

Exemple 1

 Customer customer = null;
 ...
 customer.Save();

Le code est clairement faux, et il n'y a aucune solution, il appelle une méthode sur une référence nulle. Il arrive de ne pas planter car Saveil n’accède à aucune donnée d’instance; c'est comme appeler une fonction statique. Mais tout petit changement n'importe où peut provoquer soudainement un code cassé qui ne plante pas: commencer à planter.

Mais , il n'est pas non plus inconcevable de corriger le code:

Customer customer = null;
...
customer = new Customer();
try
   ...
   customer.Save();
   ...
finally
   customer.Free();
end;

pourrait introduire un crash; une non découverte par des tests unitaires avec une couverture complète et des tests manuels par l'utilisateur.

Exemple 2

float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);

Les personnes connaissant la physique reconnaîtront qu'elle est supposée être R ² au dénominateur.

Le code est faux, c'est absolument faux. Et surestimer la vitesse provoquera un tir trop tôt des fusées rétro, tuant tous les occupants du vaisseau spatial.

Mais il est également possible que le fait de surestimer la vitesse masque un autre problème: les coussins gonflables ne peuvent pas se déployer tant que la navette se déplace trop rapidement. Si nous corrigeons soudainement le code:

float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);

Maintenant, la vitesse est précise et, tout à coup, les airbags se déploient alors qu'ils ne le devraient pas.

Exemple 3

Voici un exemple que j'avais récemment, vérifiant si une chaîne contient des caractères non valides:

if (StrPos(Address, "PO BOX") >= 0)
{
   //Do something
}

Et s'il s'avère qu'il y a un bug dans la Do somethingbranche? Correction du code manifestement incorrect:

if (StrPos("PO BOX", Address) >= 0)
{
   //Do something
}

Corrige le code, mais introduit un bogue.

À mon avis, il y a deux possibilités:

• corrige le code et est blâmé pour l'avoir brisé
• attendre que le code plante, et se faire reprocher d'avoir un bogue

Que faites- vous politiquement?

Exemple 4 - Le bug du monde réel d'aujourd'hui

Je construis un objet, mais j'appelle le mauvais constructeur:

Customer customer = new Customer();

Il s'avère que le constructeur "sans paramètre" est en réalité un constructeur paramétré à partir de l'arrière de la chaîne d'héritage:

public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)

L'appeler est une erreur, car il contourne tous les constructeurs suivants.

Je pourrais changer la lignée de l'objet pour ne pas exposer un constructeur aussi dangereux, mais je dois maintenant changer le code pour:

Customer customer = new Customer(depends);

Mais je ne peux pas garantir que ce changement ne cassera rien. Comme dans l' exemple 1 ci-dessus, peut-être que quelqu'un, quelque part, dans certaines conditions ésotériques, dépend de ce qui est construit Customerpour être invalide et rempli de bric-à-brac.

Peut-être que l' Customerobjet, maintenant qu'il est correctement construit, permettra à du code de s'exécuter comme jamais auparavant, et je peux maintenant avoir un crash.

Je ne peux pas parier la vie de votre femme dessus.

Et je peux le tester d'ici à mardi, je ne peux pas jurer sur la vie de votre fille que je n'ai pas introduit de régression.

Est ce que je:

• Corriger le code et se faire reprocher de l'avoir brisé? ou
• Quitter le bogue et se faire blâmer quand le client le trouve?

Cela dépend énormément de la situation, du bogue, du client et de l'entreprise. Il y a toujours un compromis à prendre entre corriger la mise en œuvre et potentiellement introduire de nouveaux bogues.

Si je devais donner une directive générale pour déterminer quoi faire, je pense que cela donnerait quelque chose comme ceci:

1. Connectez-vous le défaut dans le système de suivi de votre choix. Discutez avec la direction / collègues si nécessaire.
2. S'il s'agit d'un défaut aux conséquences potentiellement désastreuses (par exemple, votre exemple n ° 2), lancez, criez, sautez de haut en bas jusqu'à ce que quelqu'un qui a l'autorité en soit informé et détermine la marche à suivre appropriée pour atténuer les risques associés au correctif. Cela peut repousser votre date de sortie, sauver des vies, laver vos fenêtres, etc.
3. S'il s'agit d'un défaut irréversible ou s'il existe une solution de contournement, évaluez si le risque de le réparer l'emporte sur les avantages du correctif. Dans certaines situations, il est préférable d’attendre que le client l’affiche, car vous savez alors que vous ne perdez pas de temps à réparer ou à réessayer des tâches qui ne sont pas obligatoires à 100%.

Remarquez, cela ne s'applique que lorsque vous êtes sur le point de sortir un communiqué. Si vous êtes en mode de développement complet, il suffit de consigner le défaut pour pouvoir le suivre, le corriger et l'appeler comme il se doit. Si cela prend plus d'une demi-heure, par exemple, à réparer et à vérifier, je demanderais au responsable de l'équipe ou au responsable de l'équipe de vérifier si le défaut doit être intégré dans le cycle de publication actuel ou programmé ultérieurement.

Les clients trouveront TOUJOURS des bugs . Il n'y a pas de bugs cachés des clients, jamais. En fin de compte, les bogues que vous introduisez vous reviendront toujours. Ne pas les réparer est simplement une mauvaise pratique professionnelle. Les professionnels ne le font pas.

Lorsque les clients trouvent des bogues, la société semble mauvaise, pas un développeur individuel. C’est bien pire pour l’entreprise, vous avez donc tout intérêt à faire le changement. Si vous n'êtes pas vraiment sûr de faire ce changement et que vous craignez d'introduire d'autres bogues, adressez-vous à un développeur plus expérimenté, au responsable technique du projet ou à toute autre personne en mesure de prendre une décision concernant ce changement et d'en gérer les conséquences.

Corriger le bug

Nous sommes des professionnels ici. Si vous trouvez dans le code un chemin défaillant susceptible de provoquer un blocage ou un comportement incorrect, vous devez y remédier. Selon les procédures de votre équipe, vous devrez probablement signaler un défaut, éventuellement écrire un test de régression et enregistrer le correctif au bon moment du cycle du navire. S'il s'agit d'un bogue de faible priorité, la vérification du correctif au début d'un jalon est toujours un bon moment, car si vous provoquez une régression, vous n'affecterez pas le cycle de publication du jalon.

Ne confondez pas cela avec la refactorisation ou l'amélioration des performances qui ne sont pas liées à un bogue de performance.

Un système de contrôle de sources distribué où vous pouvez conserver un référentiel séparé contenant les "petites corrections de bogues", puis les fusionner facilement au début d'un jalon est une aide précieuse.

Que dirait le client?

Voici comment j'imagine que cela se joue:

Client: Il se bloque quand je fais x.

Programmeur: Ah oui! Je me souviens que j'ai vu cela il y a quelque temps. Je pensais que ce n'était pas encore grave, donc je l'ai laissé là.

Client: [atteint un objet contondant]

Oui. Corrigez le bug. Vous épargnerez au client une expérience aggravante et vous devrez le réparer avant que cela devienne une urgence.

Et si vous pensez que votre solution peut réellement provoquer un blocage, vous n'avez pas encore trouvé de solution.

Tous les exemples que vous avez donnés semblent avoir un dénominateur commun. Vous semblez vouloir corriger un bogue que vous ne comprenez pas bien. Je dis cela parce que vous notez la possibilité de conséquences inattendues pour chacune d’elles.

Je dirais que c'est probablement une grave erreur et, comme Ben Laurie l'écrit , ne corrige pas un bug que vous ne comprenez pas . Dans cet exemple célèbre, l’équipe Debian a rompu le cryptage d’OpenSSL pour Debian et de produits dérivés tels que Ubuntu en suivant les résultats d’un outil d’analyse.

Si vous croyez qu'il y a un défaut en consultant le code, assurez-vous de pouvoir reproduire le défaut de manière visible par le client. Si vous ne pouvez pas, pourquoi ne pas dépenser vos ressources pour réparer autre chose.

Commencez à réduire votre dette technique dès que possible .

Vos exemples ressemblent définitivement à du code hérité , avec beaucoup de dettes techniques et je sens qu'il y a une peur du changement (BTW, ce n'est pas une critique ni un jugement). Toute votre équipe doit reconnaître que vous avez cette dette technique (vous ne pouvez donc pas la reprocher à elle seule) et vous pourrez alors décider de la façon dont vous allez la gérer.

Dans l'exemple 1, si Save()n'accède à aucune donnée d'instance, quelles données client est-il sauvegardé exactement? Commencez à réparer et à tester cela.

Dans l'exemple 2, il est facile de couvrir le calculateur de vitesse avec des tests et de s'assurer qu'il calcule le résultat correct dans tous les exemples clés.

Dans l'exemple 3, il est dangereux de ramener du code mort à la vie. Ce code devrait-il être complètement éliminé? Quelle est l'intention de la condition booléenne dans ce cas? Est-ce pour s'assurer que la chaîne ne contient aucun caractère invalide? Ou pour vous assurer qu'il contient "PO BOX"? Le plus tôt vous commencez à répondre à de telles questions, mieux ce sera.

Après avoir résolu un certain nombre de problèmes, organisez une sorte de rétrospective / post-mortem avec votre équipe. Il est important de tirer les leçons de cette expérience pour pouvoir réduire votre taux d’injection de défauts à l’avenir.

Vous avez déjà de bonnes réponses. Je vais juste ajouter quelque chose à propos de la crainte que quelque chose se bloque.

Premièrement, dans l’idéal, le logiciel est modulaire, correctement architecturé et les problèmes sont bien séparés. Dans ce cas, il est très peu probable que les modifications que vous apportez brisent quoi que ce soit car vous maîtriserez tout le code associé et il n'y aura pas de surprises cachées.

Malheureusement, la situation idéale est fictive. Quel que soit le degré de couplage, il y aura couplage et donc possibilité de casser autre chose.

La solution à ce problème est double:

1. Rendez le code aussi structuré que possible.
2. Lorsque le code est suffisamment isolé pour que vous sachiez que rien d'autre ne se cassera, corrigez-le.

Rendre le code bien structuré ne se fait pas en réécrivant tout le code dans une nouvelle conception architecturale. Ici, le refactoring guidé par des tests est votre ami. Dans cette étape, vous ne modifiez pas la fonctionnalité.

La deuxième étape consiste à corriger le bogue.

Quelques points sont pertinents:

1. Le contrôle de version est absolument nécessaire pour ce processus.
2. Les étapes de refactoring et de correction de bogues sont mieux validées dans le contrôle de version en tant que validations distinctes, afin que chacune ait une fonctionnalité historique bien définie.
3. Ne vous concentrez pas sur la possibilité de créer un autre bogue, vous ne pourrez rien faire. Pensez plutôt à améliorer votre code. En d'autres termes, à moins que vous ne sachiez que vous augmentez le nombre de bugs plutôt que de les réduire, vous devriez le faire.
4. Relatif au dernier point: n'essayez pas de prédire l'avenir. Les humains ont tendance à penser qu'ils sont très bons prédicteurs. En réalité, nos prédictions sont à court terme. Donc, ne vous inquiétez pas d'un futur bogue indéfini. C’est aussi le principe de YAGNI .
5. L'outil correspondant au contrôle de version dans le monde des bogues est le traqueur de bogues . Vous en aurez besoin aussi.
6. Vous devez corriger les bogues pour deux raisons: pour satisfaire le client; et afin de pouvoir progresser dans votre développement. Pour utiliser l'exemple 3 (celui de la physique): si le programme satisfait le client avec une telle équation cassée, de nombreuses autres parties du logiciel sont mal développées pour atténuer ce bogue (par exemple, le déploiement de l'airbag). Si une version 2 (ou 1.1) est requise pour ce logiciel, il vous sera de plus en plus difficile de développer un code correct basé sur celui-ci. Vous vous dirigez alors soit vers la grande réécriture, soit vers le grand échec. Vous devriez éviter les deux.

Ce sont déjà plus que quelques points, alors je suppose que je vais m'arrêter ici.

Vous devez d’abord considérer la définition d’un bogue:

1. Le code lu ne correspond pas à ce que vous pensez avoir raison
2. Le logiciel n'effectue pas correctement ses tâches

Vous semblez vous concentrer sur le n ° 1, le n ° 2 étant le meilleur endroit pour s'asseoir. Bien sûr, nous, les programmeurs, voulons que notre code soit correct (n ° 1), mais les gens nous paient pour que cela fonctionne (n ° 2).

Ce que vous pouvez ou ne pouvez pas faire à la base de code et qui pourrait introduire accidentellement de nouveaux bogues est sans importance pour la vue # 2 du logiciel actuel. Cependant, le n ° 1 est important pour vous ou le programmeur de maintenance qui suit. Il est parfois difficile de décider, mais lorsque les conflits n ° 2 et n ° 1, vous devez savoir que le n ° 2 est clairement plus important.

Ni. Il existe un troisième moyen: trouver un moyen de prouver que "le code problématique" pose effectivement problème du point de vue commercial. Confirmez ce que vous trouvez avec BA / QA ou au moins votre responsable. Ensuite, planifiez le correctif lorsque tout le monde est au courant du problème.

Il existe plus de scénarios possibles qu'un bogue valide dans les cas que vous avez mentionnés:

1. Le code que vous regardez est un code mort. C'est peut-être parce que, comme le disait ysolik: les clients trouvent toujours des bogues. S'ils ne l'ont pas fait, le code n'est peut-être jamais exécuté.
2. Il y avait une situation WTF où l'erreur évidente avait son but. (Nous parlons de code de production, tout aurait pu arriver, non?)
3. Les entreprises / clients étaient déjà au courant du problème, mais ils ne ressentaient pas le besoin de trouver une solution.
4. Peut-être plus...

Dans tous les cas ci-dessus, si je suis un responsable, je ne souhaite pas que les développeurs utilisent son jugement et corrigent "l'erreur" en place. Corriger l'erreur en place peut être utile dans la plupart des cas, mais si elle tourne mal, cela peut causer plus de problèmes que ses bonnes intentions.

Est ce que je:

• réparer le code et se faire reprocher de le casser? ou
• laisser le bogue et se faire blâmer quand le client le trouve?

Vous corrigez le bogue, démarrez les tests unitaires et, lorsqu'ils réussissent, vous enregistrez votre correctif.

(Ou, si vos tests unitaires prennent beaucoup de temps, vous archivez d'abord votre correctif, puis attendez que votre outil de configuration vous envoie un courrier car votre commit a violé quelque chose.)

Corrigez-les s'il s'agit de bugs liés à un crash / une perte de données. Envoyer un programme avec un bug de perte de données connu est carrément malveillant et inexcusable.

Si le bogue est cosmétique ou non critique (peut être évité), il doit être documenté et une solution de contournement doit être fournie. Idéalement, cela devrait être corrigé, mais il est parfois trop coûteux de le corriger pour la version actuelle.

Notez que chaque projet logiciel plus important comporte une section «Problèmes connus» dans le fichier Lisez-moi, qui répertorie généralement exactement cela: Bogues connus.

Connaître les bogues et NE PAS les communiquer n’est acceptable à mon humble avis que pour les bogues vraiment mineurs / esthétiques.

Corrigez-le et faites-le tester. Si vous décidez de conserver les bogues connus simplement parce que vous avez peur de trouver d'autres bogues, votre programme devient un champ de mines de bombes à retardement si rapides qu'il deviendra irréparable plus tôt que vous ne le pensez.

Puisque vous êtes le maître et que le code est le subordonné, vous pouvez ne pas avoir peur de le changer quand vous voyez que c'est faux. La peur du code ("il pourrait exercer des représailles en cassant ailleurs") est tout simplement inacceptable.

S'il y a clairement un coup de poing ou quelque chose qui ne va pas , alors vous devriez le réparer. En cas d’ambiguïté dans la spécification, c’est-à-dire si vous vous trouvez en train de penser «le client peut s’y attendre, mais cela ressemble à cela. pourrait s'agir d'un bogue" ou d'un problème dans la spécification, comme "on nous a demandé de le faire. mais ça craint "alors vous devez savoir quoi faire. Envoyer le code par-dessus le mur et attendre les commentaires des clients est une mauvaise chose. Vous pouvez demander à un responsable produit si vous en avez un ou demander au client avant de déployer le produit.

Rappelez-vous, "nous connaissons ce problème et nous le corrigerons dans une prochaine version" est synonyme de "nous connaissons ce problème mais ne vous souciez pas de vous assez pour vous éviter de le traiter".

La bonne chose à faire n'est ni d'ignorer le bogue, ni de le "réparer" sur-le-champ; pour les raisons mêmes que vous avez identifiées dans votre question.

Je pense que vous devriez d'abord essayer de comprendre le code. Si le code que vous voyez a un certain âge et que personne n'a encore remarqué le "bogue", il y a probablement une raison à cela. Essayez de trouver cette raison. Voici ce que je voudrais examiner avant de prendre une décision:

• Historique : Utilisez votre logiciel de contrôle de version pour répondre aux questions suivantes: Qui a touché le code? Qu'ont-ils changé? Et avec quels messages de commit l'ont-ils archivé? Pouvez-vous déduire une raison pour laquelle le code ressemble à cela?

• Utilisation : Quel code utilise le code défectueux? Et comment? Le code est-il mort? Existe-t-il un autre code qui repose sur le comportement défectueux?

• Auteur : si vous ne parvenez pas à une conclusion rapide en utilisant les informations ci-dessus, demandez à l'auteur du code (du moins si cela est possible) pourquoi le code a la même apparence. Habituellement, vous aurez soit un "Oups, cela devrait être corrigé!" ou un "Non! Ne le changez pas !!! C'est nécessaire de cette façon!" tout de suite.