Come trattare i bug che gli utenti pensavano fossero una caratteristica?

I'm guessing that if a large percentage of users expected it as a feature, it should be left "unfixed" or "fixed" to be more stable?

Il bug aggiunge valore? Se è così, è più di una caratteristica. A volte un "bug" può diventare una "funzione" aggiunta di valore.

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

In this specific case, it's a bug in an API of an internally-used library that other developers use.

In questo caso, includerei una correzione come parte del tuo prossimo cambio di rottura rispetto alla retrocompatibilità. non puoi realizzarlo davvero in modo coerente nella maggior parte degli ambienti e probabilmente c'è una pianificazione / tempistica per questo.

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

Per lo meno, crea internamente una sorta di "bug noto con la versione corrente" di documenti / wiki e così puoi garantire che tutti gli utenti interni sappiano che la funzionalità è simile a un bug. Speriamo che abbiate sufficienti test che coprono le aree in cui le persone utilizzano la funzionalità bug-as-a-one per vedere dove / quando le cose si interrompono quando / se sistemate 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 tirarlo fuori.

Un buon esempio di questo è la meccanica "Sci" nel videogioco "Tribes". Originariamente un bug nel modo in cui il motore della fisica ha gestito il salto su una collina, è finito con una delle meccaniche di base del gioco. Puoi leggere un po 'di più a riguardo qui , se sei curioso.

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

1. Crea un clone della funzione di libreria errata. In molti casi, in questi casi, le persone semplicemente aggiungono un 2 al nome della funzione, 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. Dichiara la funzione originale come deprecata.

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

Questo approccio è particolarmente utile per le funzioni la cui interfaccia è fondamentalmente interrotta: non si rompe il codice utente subito, ma si dà il dovuto avviso a chiunque faccia affidamento sul codice non funzionante per passare all'utilizzo del codice fisso. E anche se le persone non prestano attenzione all'avvertimento, non possono davvero biasimarti quando rimuovi effettivamente la funzione rotta.

In this specific case, it's a bug in an API of an internally-used library that other developers use.

Se quegli altri sviluppatori ritenevano che il comportamento fosse una funzionalità, è probabile che lo abbiano usato e abbiano creato software funzionante su di esso. La correzione del bug probabilmente interromperà il codice esistente e ti daranno la colpa per questo. Ciò rende la correzione del bug un compromesso, e devi considerare

• è davvero importante correggere il bug, ad esempio perché c'è un alto rischio di far sì che gli utenti della tua API blocchino le loro applicazioni nel caso in cui il bug non sia corretto? O si tratta solo della coerenza dell'API?

• o è più importante mantenere il software esistente stabile e la libreria compatibile all'indietro?

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 modificare il loro software, la quantità di software che si interromperà se tu cambia la tua API, ma anche i rischi di ciò che potrebbe accadere se non correggi l'API.

Solo perché si documenta la modifica del bugfix in un "elenco di modifiche irrisolte nella prossima major release" non rendi felici i tuoi clienti - se lo fai, ci dovrebbe essere almeno qualche ragionamento a prova di proiettile perché non puoi permettere al API come era prima. Spesso mantenere la compatibilità con le versioni precedenti è più importante della correzione di un bug. Quindi aggiustalo solo se puoi stimare l'impatto sulla tua base di utenti e il loro software e sei certo che non produrrai sforzi irragionevoli per loro quando tenteranno di aggiornare la tua ultima versione della libreria. E se non hai abbastanza informazioni per fare una buona stima su questo, sarà probabilmente meglio non cambiare il comportamento.

(E sì, se stai per fare una modifica API che non è retrocompatibile, i tuoi numeri di versione devono esprimerlo chiaramente, non importa se lo chiami "bugfix" o meno).

Abbracciarlo. Può rendere tutto il tuo prodotto.

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

Lo hanno risolto alla fine, ma la gente lo odiava così tanto che gli sviluppatori lo hanno seriamente bloccato.

Quindi la mia risposta è stabilizzare e mantenerla (refactator se necessario).

Quella bella storia è stata detta, non penso che la stessa risposta valga per qualsiasi cosa che non abbia un vantaggio diretto. Se il tuo bug causa un evento che causa il vantaggio, di solito sarà più intelligente correggere il bug e trovare un altro modo per ottenere tutto ciò che potrebbe. Se è fuori dal campo di applicazione, prendi in considerazione l'idea di lasciarlo fuori solo per essere fuori dal campo di applicazione, o creare un altro modulo (forse uno piccolo) per introdurlo. Fondamentalmente: non violare il principio di responsabilità singola .