Quand les corrections de bugs deviennent-elles excessives, si jamais?


128

Imaginez que vous créez un lecteur vidéo en JavaScript. Ce lecteur vidéo boucle la vidéo de l'utilisateur de manière répétée à l'aide d'une fonction récursive et, de ce fait, le navigateur en déclenche une too much recursion RangeErrorà un moment donné.

Probablement personne n'utilisera autant la fonction de boucle. Votre application ne générera jamais cette erreur, même si l'utilisateur a laissé l'application en boucle pendant une semaine, mais elle existe toujours. Pour résoudre ce problème, vous devrez repenser le fonctionnement de la mise en boucle dans votre application, ce qui prendra un temps considérable. Que faire? Pourquoi?

  • Corriger le bug

  • Laisser le bug

Ne devriez-vous pas réparer que les bugs que les gens vont trébucher? Quand les corrections de bugs deviennent-elles excessives, si jamais elles le sont?

MODIFIER:

Si l’approche récursive ne causant pas de bogue vous préoccupe, supposons que chaque fois que le lecteur boucle une vidéo, une variable est augmentée 1. Après 2 53 boucles, cette variable débordera et votre programme ne pourra pas la gérer, lançant une exception.


95
Ne plaisante pas avec mon exemple de scénario
Tiago Marinho,

15
@PlasmaHH J'utilise ce scénario hypothétique pour expliquer ma question. Que le bogue existe ou non, cela n'a pas d'importance
Tiago Marinho

13
@TiagoMarinho: ce que j'essaie de dire, c’est: c’est parfois la bonne chose à faire pour définir un tel scénario comme étant le comportement souhaité.
PlasmaHH

23
Pourquoi diable courriez-vous une telle boucle en utilisant la récursivité en premier lieu? Vous ne voudrez peut-être pas résoudre le bogue, mais vous devrez certainement reconsidérer votre processus de conception :-)
jamesqf

28
Cela ressemble plus à une question d’affaires. Vous devez définir des priorités en fonction du coût à corriger, de l'impact / de la fréquence du bogue.
Casey Kuball

Réponses:


164

Vous devez être pragmatique.

S'il est peu probable que l'erreur se produise dans le monde réel et que le coût de la réparation soit élevé, je doute que de nombreuses personnes y voient un bon usage des ressources à réparer. Sur cette base, je dirais de laisser tomber mais de veiller à ce que le piratage soit documenté pour vous ou votre successeur dans quelques mois (voir le dernier paragraphe).

Cela dit, vous devriez utiliser ce problème comme une "expérience d'apprentissage" et la prochaine fois que vous utiliserez la boucle, n'utilisez pas inutilement une boucle récursive.

Aussi, soyez prêt pour ce rapport de bogue. Vous seriez surpris de voir à quel point les utilisateurs finaux sont capables de repousser les limites et de détecter les défauts. Si cela devient un problème pour les utilisateurs finaux, vous devrez le résoudre - alors vous serez heureux de documenter le piratage.


119
Totalement d’accord avec "Vous seriez surpris de voir à quel point les utilisateurs finaux sont capables de dépasser les limites et de détecter les défauts."
Repéré

74
Les utilisateurs finaux ne sont aucunement limités par ce que vous pensez être une utilisation raisonnable de votre logiciel. Il y aura des utilisateurs qui veulent boucler une vidéo pour toujours. C'est une fonctionnalité fournie par votre logiciel, ils l'utiliseront donc.
gnasher729

36
@ gnasher729 Les vidéos "10 heures XXXX" sur Youtube sont un bon identifiant. En effet, certaines personnes veulent simplement boucler quelque chose pour toujours.
Chris Cirefice

23
Un autre problème: si votre logiciel est populaire, alors quelqu'un rencontre un bogue qui survient dans une situation rare, le publie sur Internet, et soudain tout le monde et son chien disent: "ce logiciel est nul, il se bloque si je boucle une vidéo un jour". Ou un concurrent l'utilise pour démontrer à quel point il est facile de bloquer votre application.
gnasher729

4
Accent mis sur le dernier paragraphe. Saviez-vous que MacOS Classic se bloquerait s'il recevait 32 768 événements consécutifs de "pression de la souris" sans événement intermédiaire de "libération de la souris"?
Mark

79

Un problème similaire dans Windows 95 provoquait le blocage des ordinateurs après 49,7 jours . Cela n'a été remarqué que quelques années après sa publication, car très peu de systèmes Win95 sont restés aussi longtemps actifs. Donc, il y a un point: les bogues peuvent être rendus non pertinents par d'autres bogues plus importants.

Ce que vous devez faire, c'est une évaluation des risques pour le programme dans son ensemble et une évaluation de l'impact de chaque bogue.

  • Ce logiciel est-il sur une frontière de sécurité?
  • Si oui, ce bogue peut-il donner lieu à un exploit?
  • Ce logiciel est-il "critique" pour les utilisateurs auxquels il est destiné? (Voir la liste des choses pour lesquelles le CLUF de Java vous interdit de l'utiliser )
  • Le bogue peut-il entraîner une perte de données? Perte financière? Perte de réputation?
  • Quelle est la probabilité que ce bug se produise? (Vous avez inclus cela dans votre scénario)

Etc. Cela affecte le tri des bogues , le processus de choix des bogues à corriger. Presque tous les logiciels d’expédition ont une très longue liste de bugs mineurs qui n’ont pas encore été jugés suffisamment importants pour être corrigés.


2
Je rappelle également le bogue (matériel) dans certains processeurs Intel où une valeur spécifique en virgule flottante s'est mal passée.

5
@WilliamKappler en.wikipedia.org/wiki/Pentium_FDIV_bug est ce à quoi je pense que vous faites allusion. Était en place pendant un an avant que quiconque le remarque.
Jeutnarg

10
@ gnasher729 - Pas vraiment, ils étaient déjà au bas et creusaient encore :) La plupart des gens ont dû réinstaller Win 95 plus souvent que 49,7 jours IIRC.
Mcottle

4
@Luaan Le commentaire se voulait une fouille joyeuse à M $, d'où le smiley après la première phrase. Ils étaient en retard sur la balle avec 95 parce qu’elle était sortie très tard en 95 (probablement parce que la sortie de Win95 en 1996 aurait été un mauvais look), à moitié cuite (Remember the USB BSOD?) Et encline à devenir instable et à nécessiter des réinstallations régulières D'où ma deuxième phrase - qui n'a jamais mentionné l'exécution d'un serveur sous Windows 95, je ne sais pas d'où vous tirez CELA (flashbacks?). La deuxième version du CD a amélioré les choses, mais la première version de '95 était un doozy.
Mcottle

5
TBH Je pense que c’était le fiasco "Windows for Warships" qui causait le plus de dommages à la réputation ( archive.wired.com/science/discoveries/news/1998/07/13987 ) et qui utilisait NT. Les machines Unix de cette époque pouvaient gérer des périodes de disponibilité de plusieurs années, même en utilisant des versions (très anciennes) de Linux. Tous les ordinateurs domestiques étaient également capables de fonctionner très longtemps, bien qu’ils soient rarement utilisés de cette façon. J'ai vu des micros de la BBC intégrés à des expositions éducatives une décennie après leur obsolète.
pjc50

33

Les autres réponses sont déjà très bonnes, et je sais que votre exemple n’est qu’un exemple, mais je tiens à souligner une grande partie de ce processus qui n’a pas encore été discutée:

Vous devez identifier vos hypothèses, puis les tester par rapport aux cas critiques.

En regardant votre exemple, je vois quelques hypothèses:

  • L'approche récursive finira par provoquer une erreur.
  • Personne ne verra cette erreur car la lecture des vidéos prend trop de temps pour atteindre la limite de pile.

D'autres personnes ont discuté de la première hypothèse, mais regardez la deuxième hypothèse: que se passe-t-il si ma vidéo ne dure qu'une fraction de seconde?

Et bien sûr, ce n’est peut-être pas un cas d’utilisation très courant. Mais êtes-vous vraiment sûr que personne ne téléchargera une très courte vidéo? Vous supposez que les vidéos ont une durée minimale et vous n'avez probablement même pas réalisé que vous supposiez quoi que ce soit! Cette hypothèse pourrait-elle causer d'autres bogues à d'autres endroits de votre application?

Les hypothèses non identifiées sont une source énorme de bugs.

Comme je l'ai dit, je sais que votre exemple n'est qu'un exemple, mais le processus d'identification de vos hypothèses (qui est souvent plus difficile qu'il n'y paraît) et le fait de penser à des exceptions à ces hypothèses sont également un facteur déterminant pour décider où passer votre temps.

Donc, si vous vous trouvez en train de penser "je ne devrais pas avoir à programmer autour de ça, car cela n'arrivera jamais", alors vous devriez prendre un peu de temps pour vraiment examiner cette hypothèse. Vous penserez souvent à des cas particuliers qui pourraient être plus courants que vous ne le pensiez au départ.

Cela étant dit, il y a un moment où cela devient un exercice futile. Vous ne vous souciez probablement pas de savoir si votre application JavaScript fonctionne parfaitement sur une calculatrice TI-89, aussi perdez-vous du temps.

Les autres réponses ont déjà abordé cette question, mais la distinction entre "c'est important" et "c'est une perte de temps" n'est pas une science exacte, elle dépend de nombreux facteurs qui peuvent être complètement différents personne ou entreprise à une autre.

Mais une partie importante de ce processus consiste d'abord à identifier vos hypothèses, puis à reconnaître les exceptions à ces hypothèses.


Très bon point Kevin. Notez mon commentaire sur la réponse sélectionnée ci-dessus qui se concentre sur la question d'analyseWhat's the worst thing that could happen?
OMY

Une autre hypothèse est qu’une pile en croissance constante ne posera des problèmes que si elle atteint une taille de débordement. En fait, la pile peut être une ressource normale, ce bogue fuit constamment. L'ensemble du navigateur pourrait devenir de plus en plus lent de minuscules bits à chaque itérat ^ H ^ H ^ H ^ H ^ H ^ Hrecursion.
Alfe

1. Le PO n'a jamais dit que le problème était causé par une pile grandissante. Cela pourrait tout aussi bien être causé par une erreur dans une routine de compteur (dec -> div / 0?). 2. Si le problème est un problème de débordement de pile, cette question ne devrait-elle pas être postée dans StackOverflow? <rimshot!> ;-D
OMY

@OMY À qui s'adresse ce commentaire?
Kevin Workman

13

Je vous recommande de lire le document suivant:

La fiabilité et ses menaces: une taxonomie

Il décrit entre autres divers types de défauts pouvant survenir dans votre programme. Ce que vous avez décrit s'appelle une faute dormante et est décrit comme suit dans cet article:

Un défaut est actif lorsqu'il produit une erreur, sinon il est en sommeil. Une défaillance active est soit a) une défaillance interne qui était auparavant dormante et qui a été activée par le processus de calcul ou les conditions environnementales, ou b) une défaillance externe. L'activation de défaut est l'application d'une entrée (le modèle d'activation) à un composant qui active un défaut en sommeil. La plupart des défauts internes alternent entre leurs états dormant et actif

Cela dit, tout se résume à un rapport coûts-avantages. Le coût serait composé de trois paramètres:

  • À quelle fréquence le problème se présenterait-il?
  • Quelles seraient les conséquences?
  • Combien cela vous dérange personnellement?

Les deux premiers sont cruciaux. Si c'est un bogue qui se manifeste une fois dans une lune bleue et / ou que personne ne s'en soucie, ou si une solution de contournement parfaitement pratique est en place, vous pouvez le documenter en toute sécurité en tant que problème connu et passer à un problème plus stimulant et plus complexe. tâches importantes. Cependant, si le bogue entraînait l'échec d'une transaction monétaire ou interrompait un long processus d'enregistrement, frustrant ainsi l'utilisateur final, vous devez agir en conséquence. Le troisième paramètre est quelque chose que je déconseille fortement. Dans les mots de Vito Corleone:

Ce n'est pas personnel. C'est des affaires.

Si vous êtes un professionnel, laissez les émotions de côté et agissez de manière optimale. Cependant, si l'application que vous écrivez est un loisir, alors vous êtes impliqué émotionnellement et le troisième paramètre est aussi valide que possible pour décider de corriger un bogue ou non.


«Ce n'est pas personnel. Ses affaires sont de Michael, je suppose, pas de Vito. (Vous seriez surpris de voir à quel point les utilisateurs finaux sont
capables de

En fait, c'est par Vito, si vous lisez le livre. Même dans le film, Tom Hagen a déclaré cela en premier lieu lorsqu’il discutait avec Sonny de la question de savoir s’ils devaient aller au matelas, et seulement après cela, Michael a dit la célèbre citation: "Ce n’est pas personnel, Sonny. C’est strictement commercial .. . ". Mais Hagen l'a appris de Vito.
Vladimir Stokic,

11

Ce bug ne reste inconnu que le jour où quelqu'un place votre joueur sur un écran d'accueil dans une présentation de société 24h / 24 et 7j / 7. Donc c'est toujours un bug.

La réponse à Que faites-vous? est vraiment une décision d’affaires, pas une décision d’ingénierie:

  • Si le bogue ne concerne que 1% de vos utilisateurs et que votre lecteur ne prend pas en charge une fonctionnalité requise par 20% supplémentaires, le choix est évident. Documentez le bug, puis continuez.
  • Si le correctif est sur votre liste de tâches, il est souvent préférable de le corriger avant de commencer à ajouter de nouvelles fonctionnalités. Vous bénéficierez des avantages du processus de développement logiciel zéro défaut et vous ne perdrez pas beaucoup de temps car il figure de toute façon sur votre liste.

5

Surtout dans les grandes entreprises (ou les grands projets), il existe un moyen très pragmatique d'établir ce qu'il faut faire.

Si le coût de la réparation est supérieur au retour que la correction apportera, conservez le bogue. Viceversa, si le correctif retourne plus que son coût, corrigez le bogue.

Dans votre exemple de scénario, cela dépend du nombre d'utilisateurs que vous prévoyez perdre par rapport au nombre d'utilisateurs que vous gagnerez si vous développez de nouvelles fonctionnalités au lieu de corriger ce bug coûteux.


6
Le retour sur investissement pour la correction d'un bogue est rarement facile à évaluer - vous devez généralement vous fier à votre jugement.
Ant P

Le retour que le correctif apportera est principalement une réputation qui est presque impossible à quantifier. Si je suis le seul à savoir qu'il peut y avoir un bogue et que, dans un an ou deux, je change de poste et que la nouvelle entreprise songe à intégrer un lecteur vidéo à son produit (éventuellement en vendant des millions d'unités). celui-là?
Jerry Jeremiah

@JerryJeremiah si le bogue empêche un processus métier de s'exécuter, il ne s'agit pas de réputation, cela dépend de l'importance du processus métier. Et dans tous les cas et toutes les politiques que vous appliquez pour corriger les bugs ou non, vous devez procéder à une évaluation subjective basée sur votre expérience et vos connaissances. Même si vous connaissez le nombre exact d'utilisateurs qui seront confrontés au bogue, il vous restera à faire un choix humain (la politique de retour sur investissement peut également inclure des statistiques sur les hits pour augmenter les coûts). Comme aujourd'hui, il n'y a pas de moyen mécanique de savoir a priori la meilleure chose à faire.
JoulinRouge

5

C'est pourquoi RESOLVED/WONTFIXc'est une chose. Il suffit de ne pas en abuser - la dette technique peut s'accumuler si vous ne faites pas attention. S'agit-il d'un problème fondamental dans votre conception, susceptible de causer d'autres problèmes à l'avenir? Alors corrige-le. Autrement? Laissez-le jusqu'à ce que cela devienne une priorité (si cela se produit).


5

Vous décrivez en réalité trois erreurs dans la situation:

  1. L'absence de processus permettant d'évaluer toutes les erreurs consignées (vous avez bien consigné l'erreur dans votre ticket / backlog / quel que soit le système en place, n'est-ce pas?) Pour déterminer si elle doit être corrigée ou non. C'est une décision de gestion.

  2. Le manque de compétences de votre équipe conduit à l’utilisation de solutions défectueuses comme celle-ci. Il est urgent de régler ce problème pour éviter des problèmes futurs. (Commencez à apprendre de vos erreurs.)

  3. Le problème que la vidéo peut cesser d’afficher après une très longue période.

Des trois erreurs seulement (3) pourrait ne pas avoir besoin d'être corrigé.


Merci d'avoir signalé les problèmes d'ordre 2. Trop de gens ne traitent que le symptôme et la cause continue à créer davantage de symptômes.
Jaxter

4

Il y a beaucoup de réponses ici en discutant de l'évaluation du coût de la résolution du bogue plutôt que de son départ. Ils contiennent tous de bons conseils, mais j'aimerais ajouter que le coût d'un bogue est souvent sous-estimé, voire très largement sous-estimé. La raison en est que les insectes existants embrouillent les eaux pour un développement et une maintenance continus. Faire en sorte que vos testeurs gardent une trace de plusieurs bogues "ne résolvent pas" tout en naviguant dans votre logiciel pour essayer de trouver de nouveaux bogues rendant leur travail plus lent et plus sujet aux erreurs. Quelques bugs "qui ne résoudront pas" qui n'affecteront probablement pas les utilisateurs finaux ralentiront encore le développement et le résultat sera encore plus gênant.


2

Une chose que j’ai apprise au cours de mes années de codage est qu’un bogue reviendra. L'utilisateur final le trouvera toujours et en rendra compte. Que vous corrigiez ou non le bogue est "simplement" une priorité et que les délais sont importants.

Nous avons eu des bugs majeurs (à mon avis majeurs) qui ont été décidés contre la correction dans une version, pour devenir un obstacle pour la prochaine version car l'utilisateur final est tombé dessus à maintes reprises. Le même vice-versa - nous avons été poussés à résoudre un bogue dans une fonctionnalité que personne n'utilise, mais il était pratique pour la gestion de voir.


2

Il y a trois choses ici:

Des principes

C'est un côté de la médaille. Dans une certaine mesure, j'estime qu'il est bon d'insister sur la correction des bogues (ou des mauvaises implémentations, même si elles "fonctionnent"), même si personne ne s'en aperçoit.

Regardez-le comme suit: dans votre exemple, le vrai problème n'est pas nécessairement le bogue, mais le fait qu'un programmeur pense que c'est une bonne idée d'implémenter la boucle de cette manière. Dès le premier instant, il était évident que ce n'était pas une bonne solution. Il y a maintenant deux possibilités:

  • Le programmeur n'a tout simplement pas remarqué. Eh bien ... un programmeur devrait développer une intuition sur le fonctionnement de son code. Ce n'est pas comme si la récursivité est un concept très difficile. En corrigeant le bogue (et en transpirant avec tout le travail supplémentaire), il apprend peut-être quelque chose et s'en souvient, ne serait-ce que pour éviter le travail supplémentaire à venir. Si la raison était qu'il tout simplement pas eu assez de temps, la direction peut apprendre que les programmeurs ne ont besoin de plus de temps pour créer un code de meilleure qualité.

  • Le programmeur l'a remarqué, mais l'a jugé "pas un problème". Si cela est laissé de côté, alors une culture de laisser-faire est développée qui finira par conduire à des bugs là où ça fait vraiment mal. Dans ce cas particulier, peu importe. Mais que se passe-t-il si le programmeur développe une application bancaire la prochaine fois et décide qu’une certaine constellation ne se produira jamais? Alors ça le fait. Mauvais moments.

Pragmatisme

Ceci est l'autre côté. Bien entendu , dans ce cas particulier, le problème ne serait probablement pas résolu. Mais attention, il y a du pragmatisme, puis du pragmatisme. Un bon pragmatisme suppose que vous trouviez une solution rapide, mais néanmoins solide et bien fondée, à un problème. En d'autres termes, vous évitez de trop dessiner, mais les éléments que vous implémentez sont toujours bien pensés. Le mauvais pragmatisme, c’est quand vous venez de pirater quelque chose qui fonctionne "exactement" et qui va casser à la première occasion.

Échouer vite, échouer dur

En cas de doute, échouez vite et fort.

Cela signifie, entre autres, que votre code remarque la condition d'erreur, pas l'environnement.

Dans cet exemple, le moins que vous puissiez faire est de faire en sorte que l'erreur d'exécution dure ("profondeur de la pile dépassée" ou quelque chose du genre) ne se produise pas, en la remplaçant par une exception matérielle de votre cru. Vous pouvez, par exemple, avoir un compteur global et décider de manière arbitraire que vous renflouez après 1 000 vidéos (ou un nombre suffisamment élevé pour ne jamais apparaître en utilisation normale et suffisamment bas pour fonctionner dans la plupart des navigateurs). Donnez ensuite à cette exception (qui peut être une exception générique, par exemple RuntimeExceptionen Java, ou une simple chaîne en JavaScript ou Ruby) un message explicite. Vous n'êtes pas obligé d'aller jusqu'à créer un nouveau type d'exceptions ou quoi que vous fassiez dans votre langage de programmation.

De cette façon, vous avez

  • ... documenté le problème à l'intérieur du code.
  • ... En fait un problème déterministe. Vous savez que votre exception se produira. Vous n'êtes pas à la merci des modifications de la technologie du navigateur sous-jacent (pensez non seulement au navigateur PC, mais aussi aux smartphones, tablettes ou technologies futures).
  • ... il est facile de le réparer quand vous avez finalement besoin de le réparer. Votre message indique la source du problème, vous obtiendrez un retour en arrière significatif et tout le reste.
  • ... toujours pas de perte de temps à gérer les erreurs "réelles" (rappelez-vous, vous ne vous attendez jamais à ce que l'erreur se produise).

Ma convention est de préfixer de tels messages d'erreur avec le mot "Paranoia:". Ceci est un signe clair pour moi et pour tous les autres que je ne m'attends jamais à ce que cette erreur se produise. Je peux clairement les séparer des "vraies" exceptions. Si j'en vois un comme celui-ci dans une interface graphique ou un fichier journal, je sais que j'ai un problème sérieux - je ne m'attendais pas à ce qu'il se produise, après tout. À ce stade, je passe en mode crunch (avec une bonne chance de le résoudre rapidement et assez facilement, car je sais exactement où le problème s'est produit, ce qui m'a évité beaucoup de débogage parasite).


2
Je suis désolé si vous ressentez la même chose à propos de la rapidité avec laquelle j'ai accepté une réponse. Pour ma défense, je ne savais tout simplement pas que la question susciterait plus de 10 000 vues et autant de réponses au moment de l'acceptation. Quoi qu'il en soit, je n'ai toujours pas changé d'avis sur la meilleure réponse.
Tiago Marinho

@TiagoMarinho, pas de problème, le commentaire ne vous était pas principalement destiné, et je ne m'attendais pas à ce que vous le réexaminiez. ;) Je suis plus étonné par les motivations de celui qui a voté pour supprimer ma réponse ... De plus, il y a un certain vote négatif pour plusieurs réponses ici sans aucun commentaire. Je ne sais pas si c'est comme ça que ça se passe dans cette région de SE.
AnoE

Je suis tout à fait d'accord sur l'étrange vote à la baisse
Tiago Marinho

Je me demande si, dans ce cas du moins, le traitement est meilleur que le traitement. Si vous décidez d’effectuer un traitement spécial pour un défaut de conception que vous avez déjà identifié, il est judicieux de comparer le coût total du cycle de vie de conception, ou b) en fixant simplement la conception en premier lieu.
Jaxter

@ jaxter, exactement. D'où mon approche d'ouvrir l'esprit à une correction de bogue (même si cela semble excessif), mais lorsque vous décidez de ne pas corriger le bogue, alors au moins implémentez le truc rapide. Évidemment, si la solution d'échec rapide est plus chère que le "vrai" bugfix, évitez-le et corrigez-le.
AnoE

1

Un post-it sur le bureau d'un développeur senior sur mon lieu de travail dit

Est-ce que ça aide quelqu'un?

Je pense que c'est souvent un bon point de départ pour le processus de réflexion. Il y a toujours beaucoup de choses à réparer et à améliorer - mais quelle valeur ajoutez-vous réellement? ... que ce soit en termes de facilité d'utilisation, de fiabilité, de maintenabilité, de lisibilité, de performance ... ou de tout autre aspect.


0

Trois choses me viennent à l’esprit:

Premièrement , l'impact d'un bogue identifié doit faire l'objet d' une analyse approfondie avant que la décision de laisser le bogue dans le code puisse être prise de manière responsable. (Dans votre exemple, j'ai tout de suite pensé à la fuite de mémoire représentée par la pile sans cesse croissante et susceptible de ralentir votre navigateur à chaque récursivité.) Cette enquête approfondie prend souvent plus de temps que de corriger le bogue, je préfère donc corriger le bug dans la plupart des cas.

Deuxièmement , les bugs ont tendance à avoir plus d’impact qu’on ne le pense au début. Nous connaissons tous très bien le code de travail car il s'agit du cas "normal". Les bugs par contre sont une "exception". Bien sûr, nous avons tous vu beaucoup de bugs, mais nous avons vu beaucoup plus de code fonctionner. Nous avons donc plus d'expérience sur le comportement du code de travail que sur le comportement du code buggy. Il existe de nombreux livres sur le code de travail et sur ce qu’il fera dans quelles situations. Le comportement du code buggy est pratiquement inexistant.

La raison en est simple: les insectes ne sont pas un ordre, mais un chaos . Ils ont souvent une trace d'ordre en eux (ou l'inverse: ils ne détruisent pas complètement l'ordre), mais leur nature buggée est une destruction de l'ordre recherché par le programmeur. Le chaos lui-même a tendance à ne pas être estimé correctement. Il est beaucoup plus difficile de dire ce qu'un programme avec un bogue va faire que ce qu'un programme correct fera juste parce qu'il ne correspond plus à nos schémas mentaux.

Troisièmement , votre exemple contenait l’aspect que la correction du bogue impliquerait de repenser le programme. (Si vous supprimez cet aspect, la réponse est simple: corrigez le bogue, cela ne devrait pas prendre trop de temps, car aucune refonte n'est nécessaire. Dans le cas contraire :), dans ce cas, je ne ferais plus confiance au programme tel qu'il est conçu. La refonte serait un moyen de restaurer cette confiance.

Cela dit , les programmes sont des choses que les gens utilisent, et une fonctionnalité manquante ou un deuxième bogue vraiment encombrant ailleurs peut avoir la priorité sur la résolution de votre bogue. Bien sûr, prenez ensuite le chemin pragmatique et faites d’autres choses d’abord. Mais n'oubliez jamais qu'une première estimation rapide de l'impact d'un bogue peut être totalement fausse.


2
S'il vous plaît laissez un commentaire lorsque vous votez vers le bas. Nous devrions savoir quelle est la critique pour améliorer la réponse.
Alfe

0

Probabilité faible / conséquences faibles = solution prioritaire faible

  • Si la probabilité d'occurrence est très faible
  • Si les conséquences de l'occurrence sont légères
  • Ensuite, le bogue ne constitue pas une menace, il ne s'agit donc pas d'un correctif prioritaire.

Mais cela ne peut pas devenir une béquille pour les développeurs paresseux ...

  • Qu'est-ce que "très basse ocurrence" signifie même?
  • Quelles sont les "conséquences légères" même?

Pour énoncer que la probabilité d'occurrence est très faible et que les conséquences sont légères, l'équipe de développement doit comprendre le code, les habitudes d'utilisation et la sécurité.

La plupart des développeurs s’étonnent que les choses qu’ils pensaient à l’origine ne se produiront jamais, mais se produisent souvent.

Notre système éducatif n'enseigne pas très bien les probabilités et la logique. La plupart des personnes, y compris la plupart des ingénieurs en logiciel, ont une logique et une intuition brisées en matière de rentabilité. L'expérience des problèmes du monde réel et des simulations approfondies sont le seul moyen que je connaisse pour résoudre ce problème.

Confrontez votre intuition avec des données du monde réel

Il est important de créer plusieurs journaux pour pouvoir suivre les modèles d'utilisation. Remplissez le code avec des affirmations de choses qui, selon vous, ne devraient pas se produire. Vous serez surpris qu'ils le font. De cette façon, vous pourrez confronter votre intuition avec des données précises et les affiner.

Mon exemple d'un problème bénin et d'une mesure de contrôle

Dans un site de commerce électronique sur lequel j’ai travaillé il y a longtemps, un autre programmeur a commis une erreur: dans des conditions obscures, le système a débité le client de un cent de moins que ce qui était inscrit dans les journaux. J'ai découvert le bogue parce que j'ai établi des rapports pour identifier les différences entre les journaux et les soldes de compte afin de rendre le système comptable plus résistant. Je n'ai jamais corrigé ce bug car la différence était minime. La différence était calculée quotidiennement et était inférieure à 2,00 USD par mois. Il se trouve que nous avons mis au point un tout nouveau système qui, dans un an, devrait remplacer le système actuel. Il ne sert à rien de détourner des ressources d'un projet potentiellement rentable pour réparer quelque chose qui coûte 2,00 USD par mois et qui est soumis à une mesure de contrôle appropriée.

Conclusion

Oui, il y a des bogues qu'il n'est pas nécessaire de corriger tout de suite, qui ne sont pas assez importants pour retarder le développement de nouvelles fonctionnalités. Cependant, le système doit pouvoir contrôler l’occurrence de ce bogue pour s’assurer qu’il est petit, car nous ne pouvons pas faire confiance à notre propre intuition.


-1

Je pense que cela pose la mauvaise question dès le départ.

La question n'est pas "dois-je corriger ce bogue ou ne dois-je pas le réparer". Tout développeur a une quantité de temps limitée. La question est donc "quelle est la chose la plus utile que je puisse faire en une heure, quatre heures ou une semaine".

Si corriger ce bogue est la chose la plus utile à faire, car cela améliore considérablement le logiciel pour la plupart des gens, alors corrigez le bogue. Si vous pouviez apporter des améliorations plus importantes ailleurs, en ajoutant des fonctionnalités qui manquent aux utilisateurs ou en corrigeant un bug plus important, procédez comme suit. Et des points bonus supplémentaires pour tout ce qui rend votre développement futur plus efficace.


Pas sûr que la métrique utilitaire fonctionne le mieux ici. Il est clair que l'exemple du lecteur vidéo a été conçu pour avoir un impact faible, mais même cela n'est pas infaillible. Un intervenant a déjà évoqué la boucle de promotion 24 heures sur 24 et 7 jours sur 7 dans un cas d'utilisation du lobby, et un autre pourrait être un kiosque lors d'une convention technique / vente qui se tient une semaine. Les deux coûteraient des frais de représentation et / ou d’argent à l’entreprise, ce qui n’était pas trivial.
Jaxter

Cela signifierait que la correction du bogue offre plus d'avantages que prévu à l'origine, il devrait donc être placé plus haut dans les priorités. Ainsi, vous aurez plus de succès dans la vie si votre opinion sur ce qui est le plus utile concorde avec la réalité autant que possible.
gnasher729

-2

La correction des bogues est toujours une surexploitation

Classons la partie bogue en premier.

Est-ce une erreur honnête , par exemple une erreur ponctuelle ou une ombrage variable qui échappe aux tests? Dans ce cas, j’espère bien qu’en plus de "résoudre" le problème, vous avez également écrit de nouveaux tests unitaires, vous en avez profité pour refactoriser le code le plus proche, où tout ce travail est utile .

Si, toutefois, il s’agit d’un défaut de conception, comme dans votre cas, vous devez réévaluer la conception ou, dans le pire des cas, désactiver cette fonction.

Alors, s'il vous plaît, n'essayez pas de le réparer .

Vous pourriez faire pire, bien sûr, vous pourriez essayer une méthodologie de piratage par piratage . La vidéo en boucle est un hack (mauvaise architecture et il y a rupture connue). Vous pouvez ajouter une limite de boucle afin que, après N itérations (que vous avez testées, soit inférieure à la limite du navigateur), la boucle se termine.

Les ramifications sont évidentes, vous devez maintenant supporter à la fois le code erroné et la nouvelle limite de boucle.

PS excuse pour la vue extrême.

PPS Une remarque sur la terminologie: vous ne pouvez pas "réparer" un bogue. Un vétérinaire pourrait peut-être, mais n'y allons pas ;-). Les problèmes sont résolus ou "corrigés", tandis que les bogues sont supprimés ou corrigés.


Voulez-vous vraiment dire que c'est toujours "overkill"? Je pense que vous avez peut-être confondu les définitions quelque part. Overkill signifie "travailler au-delà de ce qui était requis", autrement dit, c'est plus que quiconque ne devrait le faire. Vous affirmez que la correction de bugs est toujours excessive , tout en implorant les gens de ne pas trop travailler et que nous devons faire plus de travail dessus, ce qui n'a aucun sens.
doppelgreener

@doppelgreener Je vois à quel point cela peut être déroutant. la correction des bogues est une pratique terrible et ne devrait jamais être faite. D’autre part, l’adaptation de la conception ou de l’architecture logicielle à l’évolution des besoins est une bonne pratique à suivre. Même chose pour corriger les erreurs honnêtes en supposant que c'est bien fait.
Dima Tisnek

2
Je ne sais pas de quel type de correction de bugs vous parlez, mais dans mon monde actuel, "changer l'architecture" est une méthode de correction de bogues. Vous voudrez peut-être définir ce que vous collectez sous le terme "correction de bogues".
Doppelgreener

@doppelgreener - Le terme "correctif" a une signification particulière dans certaines formes de gestion de la qualité et cette utilisation spécialisée a été adoptée par de nombreux responsables de la programmation. Un " correctif " n'est qu'une solution temporaire ou une solution de contournement, alors qu'une vraie " solution " au problème nécessite l'identification et l'élimination de la " cause première ". Dans le logiciel, un bogue peut être aussi simple qu’une virgule mal placée où le correctif (corriger la virgule) EST la solution, mais si le bogue est causé par quelque chose de plus gros, le correctif (ex: limiteurs de boucle) ne sera pas identique à la solution. (refonte / réécriture).
OMY

2
@OMY Merci pour l'explication. Je pense que depuis une telle définition de « fixer » n'est pas utilisé par la question, la réponse doit répondre au sens du mot qui est utilisé.
doppelgreener
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.