Comment traiter les bogues que les utilisateurs pensaient être une fonctionnalité?

Question :

Quelle est la bonne façon de corriger un bogue qui, selon un utilisateur final, était une fonctionnalité?

Elaboration :

Je suppose que si un grand pourcentage d'utilisateurs l'attendait en tant que fonctionnalité, elle devrait être laissée "non fixée" ou "fixe" pour être plus stable? Cependant, que se passe-t-il si un très faible pourcentage d'utilisateurs s'attendent à ce que ce soit une fonctionnalité ... disons 0,1% ou 1%, et ce bogue doit être corrigé.

Théoriquement, comme il s'agit d'un correctif de bogue mineur, il peut être qualifié de PATCH comme le considère le versioning sémantique: xyZ Cependant, comme il rompt la compatibilité descendante (même pour quelques utilisateurs seulement), cela devrait être une augmentation MAJEURE: Xyz correct? Pourrait-il encore être qualifié de PATCH (car il n'était pas destiné à être une fonctionnalité) tant qu'il est documenté?

EDIT: Dans ce cas spécifique, il s'agit d'un bogue dans une API d'une bibliothèque utilisée en interne que d'autres développeurs utilisent.

Je suppose que si un grand pourcentage d'utilisateurs l'attendait en tant que fonctionnalité, elle devrait être laissée "non fixée" ou "fixe" pour être plus stable?

Le bug ajoute-t-il de la valeur? Si c'est le cas, c'est plutôt une fonctionnalité. Parfois, un «bogue» peut devenir une «fonction» à valeur ajoutée.

Il est difficile de vraiment répondre à cette question de manière concluante, car chaque situation sera différente.

Dans ce cas spécifique, il s'agit d'un bogue dans une API d'une bibliothèque utilisée en interne que d'autres développeurs utilisent.

Dans ce cas, j'inclurais un correctif dans le cadre de votre prochain changement de rupture en ce qui concerne la compatibilité descendante. Vous ne pouvez pas vraiment le faire de manière cohérente dans la plupart des environnements et il y a probablement un calendrier / calendrier pour cela.

En tant que développeur, la dernière chose que je veux traiter est une API qui a un comportement incorrect ou incohérent. Les bogues sont considérés comme tels.

À tout le moins, créez une sorte de document / wiki "bogues connus avec la version actuelle" en interne et ainsi vous pouvez vous assurer que tous vos utilisateurs internes savent que la fonctionnalité est semblable à un bogue. J'espère que vous disposez de suffisamment de tests couvrant les domaines dans lesquels les gens utilisent le bug en tant que fonctionnalité afin que vous puissiez voir où / quand les choses se cassent quand / si vous corrigez le bug.

Je recommanderais de le rendre plus stable. Les utilisateurs sont la source canonique de ce que fait votre logiciel. S'ils le veulent, et en sont venus à s'en remettre, j'y penserais à deux fois avant de le tirer.

Un bon exemple de cela est le mécanicien "Ski" dans le jeu vidéo "Tribes". À l'origine un bug dans la façon dont le moteur physique gérait les sauts sur une colline, il est devenu l'une des principales mécaniques du jeu. Vous pouvez en lire un peu plus ici , si vous êtes curieux.

Étant donné que le bogue se trouve dans une bibliothèque, voici une autre approche que vous pouvez adopter:

1. Faites un clone de la fonction de bibliothèque erronée. Dans de nombreux cas, les gens ajoutent simplement un 2au nom de la fonction dans ces cas, mais, si vous avez d'autres modifications que vous souhaitez appliquer à l'interface de cette fonction, vous pouvez également lui donner un nom complètement différent.

2. Corrigez le bogue dans le clone uniquement (et implémentez toutes les autres modifications d'interface que vous souhaitez pendant que vous y êtes).

3. Déclarez la fonction d'origine comme obsolète.

4. Supprimez la fonction d'origine dans certaines versions majeures à venir.

Cette approche est particulièrement utile pour les fonctions dont l'interface est fondamentalement cassée: vous ne cassez pas le code utilisateur tout de suite, mais vous donnez un avertissement à quiconque s'appuie sur le code cassé pour passer à l'utilisation du code fixe. Et même si les gens ne tiennent pas compte de l'avertissement, ils ne peuvent pas vraiment vous en vouloir une fois que vous avez réellement supprimé la fonction endommagée.

Dans ce cas spécifique, il s'agit d'un bogue dans une API d'une bibliothèque utilisée en interne que d'autres développeurs utilisent.

Si ces autres développeurs pensaient que le comportement était une fonctionnalité, il est probable qu'ils l'aient utilisé et qu'ils avaient construit un logiciel de travail dessus. La correction du bogue cassera probablement leur code existant, et ils vous en blâmeront. Cela rend la correction du bogue un compromis, et vous devez considérer

• est-il vraiment important de corriger le bogue, par exemple parce qu'il existe un risque élevé de laisser les utilisateurs de votre API planter leurs applications au cas où le bogue ne serait pas corrigé? Ou s'agit-il simplement de cohérence de l'API?

• ou est-il plus important de maintenir le logiciel existant stable et votre bibliothèque rétrocompatible?

La réponse à la question n'est pas toujours simple, vous devez prendre en compte le nombre d'utilisateurs possibles de votre API, la quantité potentielle de travail qu'ils auront à changer de logiciel, la quantité de logiciel qui se cassera si vous changez votre API , mais aussi les risques de ce qui pourrait arriver si vous ne corrigez pas l'API.

Ce n'est pas parce que vous documentez le changement de correction de bogue dans une "liste des changements de rupture dans votre prochaine version majeure" que vos clients sont satisfaits - si vous faites cela, il devrait y avoir au moins un raisonnement à toute épreuve pour lequel vous ne pouvez pas laisser l'API telle qu'elle est était avant. Il est souvent plus important de conserver la compatibilité descendante que de corriger un bogue. Donc, ne le résolvez que si vous pouvez estimer l'impact sur votre base d'utilisateurs et leurs logiciels et que vous êtes sûr de ne pas faire d'efforts déraisonnables pour eux lorsqu'ils essaieront de mettre à jour votre dernière version de bibliothèque. Et si vous ne disposez pas de suffisamment d'informations pour faire une bonne estimation à ce sujet, il sera probablement préférable de ne pas modifier le comportement.

(Et oui, si vous allez faire un changement d'API qui n'est pas rétrocompatible, vos numéros de version doivent l'exprimer clairement, peu importe si vous le nommez "bugfix" ou non).

Embrasse le. Il peut faire de votre produit tout entier.

GunZ: The Duel (un jeu en ligne) avait un bug que vous pouviez exploiter et constamment abuser pour changer à peu près tout le gameplay (appelé K-Style; recherchez-le sur YouTube). Cela a rendu le jeu plus difficile; il a fallu de l'habileté et l'a rendu juste incroyable et amusant .. tellement amusant que même les modérateurs l'ont ouvertement utilisé comme style de jeu principal.
C'est ce qui a fait le jeu.
Je n'ai pas joué depuis des années, mais à ce jour, en tant que joueur, c'est l'un de mes jeux préférés de tous les temps parce qu'il est tellement basé sur les compétences et tellement amusant, et tout cela est génial juste à cause d'un bug.

Ils l'ont finalement corrigé, mais les gens détestaient tellement cela que les développeurs l'ont sérieusement mis en échec.

Donc ma réponse est de la stabiliser et de la maintenir (refactoriser si besoin).

Cette belle histoire étant dite, je ne pense pas que la même réponse s'applique à tout ce qui n'a pas d'avantage direct. Si votre bogue provoque un événement qui cause l'avantage, il sera généralement plus intelligent de corriger le bogue et de trouver un autre moyen de réaliser tout ce qu'il pourrait. S'il est hors de portée, envisagez de le laisser juste pour être hors de portée, ou créez un autre module (peut-être un petit) pour l'introduire. Fondamentalement: ne violez pas le principe de la responsabilité unique .