Come trattare i bug che gli utenti pensavano fossero una funzionalità?

Domanda :

Qual è il modo corretto di affrontare un bug che un utente finale riteneva fosse una funzionalità?

Elaborazione :

Immagino che se una grande percentuale di utenti si aspettasse che fosse una funzionalità, dovrebbe essere lasciata "non fissata" o "fissa" per essere più stabile? Tuttavia, cosa succede se una percentuale molto piccola di utenti si aspetta che sia una funzionalità ... diciamo 0,1% o 1% e questo errore deve essere corretto.

Teoricamente, poiché si tratta di una correzione minore di bug, può essere considerata PATCH come considerato dal versioning semantico: xyZ Tuttavia, poiché interrompe la compatibilità all'indietro (anche solo per pochi utenti) dovrebbe essere un aumento MAJOR: Xyz corretto? Potrebbe ancora qualificarsi come PATCH (dal momento che non era inteso come una funzione) fintanto che è documentato?

EDIT: in questo caso specifico, è un bug in un'API di una libreria utilizzata internamente che altri sviluppatori usano.

Immagino che se una grande percentuale di utenti si aspettasse che fosse una funzionalità, dovrebbe essere lasciata "non fissata" o "fissa" per essere più stabile?

Il bug aggiunge valore? Se è così, è più una caratteristica. A volte un "bug" può finire come una "caratteristica" a valore aggiunto.

È difficile rispondere davvero in modo conclusivo perché ogni singola situazione sarà diversa.

In questo caso specifico, è un bug in un'API di una libreria utilizzata internamente che altri sviluppatori usano.

In questo caso, includerei una correzione come parte della tua prossima modifica definitiva rispetto alla compatibilità con le versioni precedenti. Non puoi farlo in modo coerente nella maggior parte degli ambienti e probabilmente c'è una pianificazione / tempi per questo.

Come sviluppatore, l'ultima cosa che voglio trattare è un'API che ha un comportamento errato o incoerente. I bug sono considerati questo.

Per lo meno, crea internamente una sorta di documento / wiki "bug conosciuti con la versione corrente" e così puoi assicurarti che tutti gli utenti interni sappiano che la funzionalità è simile a un bug. Spero che tu abbia abbastanza test che coprono le aree in cui le persone usano la funzionalità bug-as-a-feature in modo da vedere dove / quando le cose si rompono quando / se correggi il bug.

Consiglierei di renderlo più stabile. Gli utenti sono la fonte canonica di ciò che fa il tuo software. Se lo vogliono, e sono arrivati ​​a fare affidamento su di esso, ci penserei due volte a strattonarlo.

Un buon esempio di questo è il meccanico "Sci" nel videogioco "Tribes". Inizialmente un bug nel modo in cui il motore fisico gestiva il salto su una collina, finì per essere una delle meccaniche di gioco principali. Puoi leggere qualcosa in più qui , se sei curioso.

Poiché il bug si trova in una libreria, ecco un altro approccio che puoi adottare:

1. Crea un clone della funzione di libreria errata. In molti casi le persone aggiungono semplicemente 2a al nome della funzione in questi casi, ma, se hai altre modifiche che vorresti applicare all'interfaccia di quella funzione, potresti anche dargli un nome completamente diverso.

2. Correggi il bug solo nel clone (e implementa tutte le altre modifiche all'interfaccia che desideri mentre ci sei).

3. Dichiarare la funzione originale come obsoleta.

4. Rimuovi la funzione originale in alcune importanti versioni in arrivo.

Questo approccio è particolarmente utile per le funzioni la cui interfaccia è fondamentalmente interrotta: non si interrompe immediatamente il codice utente, ma si dà il dovuto preavviso a chiunque faccia affidamento sul codice rotto per passare all'utilizzo del codice fisso. E anche se le persone non ascoltano l'avvertimento, non possono davvero biasimarti una volta che hai effettivamente rimosso la funzione non funzionante.

In questo caso specifico, è un bug in un'API di una libreria utilizzata internamente che altri sviluppatori usano.

Se quegli altri sviluppatori pensavano che il comportamento fosse una caratteristica, è probabile che lo abbiano usato e ci abbiano costruito un software funzionante . La correzione del bug probabilmente romperà il loro codice esistente e ti daranno la colpa per questo. Questo rende il ripristino del bug un compromesso e devi considerare

• è davvero importante correggere il bug, ad esempio perché c'è un alto rischio di consentire agli utenti dell'API di bloccare le loro applicazioni nel caso in cui il bug non venga corretto? Oppure si tratta solo di coerenza dell'API?

• o è più importante mantenere stabile il software esistente e la tua libreria retrocompatibile?

La risposta alla domanda non è sempre semplice, devi prendere in considerazione il numero di possibili utenti della tua API, la quantità potenziale di lavoro che dovranno cambiare il loro software, la quantità di software che si romperà se cambi la tua API , ma anche i rischi di ciò che potrebbe accadere se non si corregge l'API.

Il solo fatto di documentare la modifica del bugfix in un "elenco di modifiche sostanziali nella prossima versione principale" non rende felici i tuoi clienti - se lo fai, ci dovrebbero essere almeno alcuni ragionamenti a prova di proiettile sul perché non puoi lasciare che l'API in quanto era prima. Spesso mantenere la compatibilità con le versioni precedenti è più importante che correggere un bug. Quindi risolvilo solo se puoi stimare l'impatto sulla tua base di utenti e sul loro software e sei sicuro che non produrranno sforzi irragionevoli per loro quando provano ad aggiornare alla tua ultima versione della libreria. E se non hai abbastanza informazioni per fare una buona stima su questo, probabilmente sarà meglio non cambiare il comportamento.

(E sì, se hai intenzione di apportare una modifica API che non è compatibile con le versioni precedenti, i numeri di versione devono esprimerlo chiaramente, non importa se lo chiami "bugfix" o no).

Abbraccialo. Può rendere l'intero tuo prodotto.

GunZ: The Duel (un gioco online) aveva un bug che potevi sfruttare e abusare costantemente per cambiare praticamente l'intero gameplay (chiamato K-Style; cercalo su YouTube). Ha reso l'intero gioco molto più impegnativo; ci voleva abilità e lo rendeva semplicemente fantastico e divertente .. così divertente che persino i moderatori lo usavano apertamente come il loro stile di gioco principale.
È ciò che ha reso il gioco.
Non giocavo da anni ma fino ad oggi, come giocatore, è uno dei miei giochi preferiti di tutti i tempi perché è così basato sulle abilità e semplicemente così divertente, e tutto questo stupore solo per un bug.

Alla fine l'hanno risolto, ma la gente odiava così tanto che gli sviluppatori hanno seriamente risolto il problema.

Quindi la mia risposta è stabilizzarsi e mantenerla (refactor se necessario).

Detto questo bellissimo racconto, non credo che la stessa risposta valga per tutto ciò che non ha un vantaggio diretto. Se il tuo bug provoca un evento che causa il vantaggio, sarà di solito più intelligente riparare il bug e trovare un altro modo per ottenere tutto ciò che potrebbe. Se è al di fuori dell'ambito, considera di lasciarlo fuori solo per essere al di fuori dell'ambito o crea un altro modulo (forse un piccolo) per introdurlo. Fondamentalmente: non violare il principio della singola responsabilità .