Immagina di creare un video player in JavaScript. Questo lettore video riproduce ripetutamente il video dell'utente utilizzando una funzione ricorsiva e, di conseguenza, il browser si attiverà a un too much recursion RangeErrorcerto momento.

Probabilmente nessuno utilizzerà così tanto la funzione loop. L'applicazione non genererà mai questo errore, nemmeno se l'utente ha lasciato il ciclo dell'applicazione per una settimana, ma esiste ancora. Per risolvere il problema dovrai riprogettare il modo in cui il loop funziona nella tua applicazione, il che richiederà molto tempo. cosa fai? Perché?

• Risolvi il bug

• Lascia il bug

Non dovresti solo correggere i bug in cui si imbatteranno le persone? Quando la correzione dei bug diventa eccessiva, se mai lo fa?

MODIFICARE:

Se l'approccio ricorsivo che non causa un vero bug è un problema per te, supponi che per ogni volta che il giocatore gira un video una variabile viene aumentata di 1. Dopo 2 ⁵³ loop questa variabile traboccerà e il tuo programma non sarà in grado di gestirla, generando un'eccezione.

Devi essere pragmatico.

Se è improbabile che l'errore si verifichi nel mondo reale e il costo da correggere sia elevato, dubito che molte persone lo considererebbero un buon uso delle risorse da correggere. Su questa base direi di lasciarlo, ma assicurati che l'hacking sia documentato per te o per il tuo successore tra qualche mese (vedi l'ultimo paragrafo).

Detto questo, dovresti usare questo problema come "esperienza di apprendimento" e la prossima volta che esegui il ciclo non usi un ciclo ricorsivo inutilmente.

Inoltre, preparati per tale segnalazione di bug. Sareste sorpresi di quanto siano bravi gli utenti finali a spingere oltre i confini e scoprire difetti. Se diventa un problema per gli utenti finali, dovrai risolverlo, quindi sarai felice di aver documentato l'hacking.

Si è verificato un errore simile in Windows 95 che ha causato l'arresto anomalo dei computer dopo 49,7 giorni . È stato notato solo alcuni anni dopo il rilascio, dato che pochissimi sistemi Win95 sono rimasti comunque così a lungo. Quindi c'è un punto: i bug possono essere resi irrilevanti da altri bug più importanti.

Quello che devi fare è una valutazione del rischio per il programma nel suo insieme e una valutazione dell'impatto per singoli bug.

• Questo software ha un limite di sicurezza?
• In tal caso, questo errore può comportare un exploit?
• Questo software è "mission-critical" per gli utenti previsti? (Vedi l'elenco delle cose per cui l'EULA Java ti vieta di usarlo )
• Il bug può causare la perdita di dati? Perdita finanziaria? Perdita di reputazione?
• Con quale probabilità si verifica questo errore? (L'hai incluso nel tuo scenario)

E così via. Ciò influenza il triage di bug , il processo di decidere quali bug correggere. Praticamente tutti i software di spedizione hanno elenchi molto lunghi di bug minori che non sono stati ancora considerati abbastanza importanti da risolvere.

Le altre risposte sono già molto buone e so che il tuo esempio è solo un esempio, ma voglio sottolineare una grande parte di questo processo che non è stato ancora discusso:

È necessario identificare le ipotesi e quindi verificare tali ipotesi rispetto ai casi angolari.

Guardando il tuo esempio, vedo un paio di ipotesi:

• L'approccio ricorsivo alla fine causerà un errore.
• Nessuno vedrà questo errore perché i video impiegano troppo tempo per essere riprodotti per raggiungere il limite dello stack.

Altre persone hanno discusso della prima ipotesi, ma guardiamo alla seconda ipotesi: cosa succede se il mio video è lungo solo una frazione di secondo?

E certo, forse non è un caso d'uso molto comune. Ma sei davvero sicuro che nessuno caricherà un video molto breve? Stai supponendo che i video abbiano una durata minima e probabilmente non ti sei nemmeno reso conto di assumere qualcosa! Questo presupposto potrebbe causare altri bug in altri punti dell'applicazione?

Ipotesi non identificate sono un'enorme fonte di bug.

Come ho detto, so che il tuo esempio è solo un esempio, ma questo processo di identificazione dei tuoi presupposti (che è spesso più difficile di quanto sembri) e quindi pensare alle eccezioni a tali presupposti è un fattore enorme nel decidere dove trascorrere il tuo tempo.

Quindi, se ti ritrovi a pensare "Non dovrei programmare intorno a questo, dal momento che non accadrà mai", allora dovresti prenderti del tempo per esaminare davvero tale presupposto. Penserai spesso a casi angolari che potrebbero essere più comuni di quanto pensassi inizialmente.

Detto questo, c'è un punto in cui questo diventa un esercizio di futilità. Probabilmente non ti importa se la tua applicazione JavaScript funziona perfettamente su una calcolatrice TI-89, quindi perdere qualsiasi tempo su questo è solo sprecato.

Le altre risposte hanno già trattato questo, ma trovare quella linea tra "questo è importante" e "questa è una perdita di tempo" non è una scienza esatta, e dipende da molti fattori che possono essere completamente diversi da uno persona o compagnia a un altro.

Ma gran parte di quel processo è prima di identificare le tue assunzioni e poi provare a riconoscere le eccezioni a quelle assunzioni.

Consiglierei di leggere il seguente documento:

Affidabilità e le sue minacce: una tassonomia

Tra le altre cose, descrive vari tipi di guasti che possono verificarsi nel programma. Quello che hai descritto è chiamato un difetto dormiente , e in questo documento è descritto in questo modo:

Un errore è attivo quando produce un errore, altrimenti è inattivo. Un errore attivo è a) un errore interno precedentemente inattivo e che è stato attivato dal processo di calcolo o dalle condizioni ambientali, oppure b) un errore esterno. L'attivazione del guasto è l'applicazione di un ingresso (il modello di attivazione) a un componente che rende attivo un guasto inattivo. La maggior parte dei guasti interni scorre tra i loro stati dormienti e attivi

Dopo averlo descritto, tutto si riduce a un rapporto costi-benefici. Il costo sarebbe costituito da tre parametri:

• Con quale frequenza si presenterebbe il problema?
• Quali sarebbero le conseguenze?
• Quanto ti disturba personalmente?

I primi due sono cruciali. Se è un bug che si manifesterebbe una volta in una luna blu e / o nessuno se ne preoccupa, o ha una soluzione perfettamente buona e pratica, allora puoi tranquillamente documentarlo come un problema noto e passare ad alcuni più impegnativi e altro compiti importanti. Tuttavia, se il bug causava il fallimento di alcune transazioni in denaro, o interrompeva un lungo processo di registrazione, frustrando così l'utente finale, allora devi agire su di esso. Il terzo parametro è qualcosa a cui sconsiglio vivamente. Nelle parole di Vito Corleone:

Non è personale Sono affari.

Se sei un professionista, lascia da parte le emozioni e agisci in modo ottimale. Tuttavia, se l'applicazione che stai scrivendo è un tuo hobby, allora sei coinvolto emotivamente e il terzo parametro è valido come un altro in termini di decisione se correggere un bug o meno.

Quel bug non viene scoperto fino al giorno in cui qualcuno mette il tuo giocatore su uno schermo della lobby che esegue una presentazione aziendale 24/7. Quindi è ancora un bug.

La risposta a cosa fai? è davvero una decisione aziendale, non ingegneristica:

• Se il bug interessa solo l'1% dei tuoi utenti e il tuo giocatore non ha il supporto per una funzione richiesta da un altro 20%, la scelta è ovvia. Documenta il bug, quindi continua.
• Se il bugfix è nella tua lista delle cose da fare, spesso è meglio correggerlo prima di iniziare ad aggiungere nuove funzionalità. Otterrai i vantaggi del processo di sviluppo del software a zero difetti e non perderai molto tempo poiché è nella tua lista comunque.

Soprattutto nelle grandi aziende (o grandi progetti) esiste un modo molto pragmatico di stabilire cosa fare.

Se il costo della correzione è maggiore del ritorno che la correzione porterà, mantenere il bug. Viceversa se la correzione restituirà più del suo costo, correggi il bug.

Nel tuo scenario di esempio dipende da quanti utenti ti aspetti di perdere rispetto a quanti utenti guadagnerai se sviluppi nuove funzionalità invece di correggere quel bug costoso.

tl; dr Ecco perché RESOLVED/WONTFIXè una cosa. Basta non abusarne - il debito tecnico può accumularsi se non stai attento. È un problema fondamentale con il tuo progetto, che potrebbe causare altri problemi in futuro? Quindi aggiustalo. Altrimenti? Lascia che sia finché non diventa una priorità (se mai lo fa).

In realtà ci sono tre errori nella situazione che descrivi:

1. La mancanza di un processo per valutare tutti gli errori registrati (hai registrato l'errore nel tuo ticket / backlog / qualunque sistema tu abbia installato, giusto?) Per determinare se dovrebbe essere corretto o meno. Questa è una decisione di gestione.

2. La mancanza di competenze nella tua squadra che porta all'uso di soluzioni difettose come questa. È urgente che questo venga affrontato per evitare problemi futuri. (Inizia a imparare dai tuoi errori.)

3. Il problema che il video potrebbe smettere di visualizzare dopo molto tempo.

Dei tre errori, potrebbe non essere necessario correggere solo (3).

Ci sono molte risposte qui che parlano della valutazione del costo della correzione del bug invece di lasciarlo. Tutti contengono buoni consigli, ma vorrei aggiungere che il costo di un bug è spesso sottovalutato, probabilmente enormemente sottovalutato. Il motivo è che i bug esistenti confondono le acque per un continuo sviluppo e manutenzione. Far sì che i tester tengano traccia di diversi bug "non risolvibili" mentre si naviga nel software cercando di trovare nuovi bug che rendono il loro lavoro più lento e più soggetto a errori. Alcuni "non risolveranno" i bug che difficilmente influenzeranno gli utenti finali rallenteranno lo sviluppo continuo e il risultato sarà più intenso.

Una cosa che ho imparato nei miei anni di programmazione è che un bug tornerà. L'utente finale lo scoprirà sempre e riporterà indietro. Indipendentemente dal fatto che si risolva il problema, il problema è "semplicemente" una priorità e una scadenza.

Abbiamo avuto grossi bug (a mio avviso importanti) che sono stati decisi contro la correzione in una versione, solo per diventare un punto fermo per la versione successiva perché l'utente finale si è imbattuto più e più volte. Lo stesso viceversa: siamo stati spinti a correggere un bug in una funzionalità che nessuno usa, ma è stato utile per la gestione.

Ci sono tre cose qui:

I principi

Questo è un lato della medaglia. In una certa misura, ritengo che è bene insistere su correggere i bug (o implementazioni cattivi, anche se "lavoro"), anche se nessuno si accorga.

Guardalo in questo modo: il vero problema non è necessariamente il bug, nel tuo esempio, ma il fatto che un programmatore abbia pensato che fosse una buona idea implementare il loop in questo modo, in primo luogo. Era ovvio sin dal primo momento che questa non era una buona soluzione. Ora ci sono due possibilità:

• Il programmatore non se ne è accorto. Bene ... un programmatore dovrebbe sviluppare un'intuizione di come viene eseguito il suo codice. Non è che la ricorsione sia un concetto molto difficile. Risolvendo il bug (e sudando per tutto il lavoro aggiuntivo), forse impara qualcosa e lo ricorda, anche solo per evitare il lavoro aggiuntivo in futuro. Se il motivo è che lui non ha avuto abbastanza tempo, la gestione potrebbe imparare che i programmatori non hanno bisogno di più tempo per creare codice di qualità più elevata.

• Il programmatore se ne accorse, ma lo considerò "non un problema". Se questo viene lasciato in piedi, allora viene sviluppata una cultura del laissez-faire che, alla fine, porterà a bug dove fa davvero male. In questo caso particolare, chi se ne frega. E se quel programmatore stesse sviluppando un'applicazione bancaria la prossima volta e decidesse che una certa costellazione non accadrà mai. Quindi lo fa. Tempi difficili.

pragmatica

Questo è l'altro lato. Di Naturalmente si sarebbe probabilmente, in questo caso particolare, non risolvere il bug. Ma attenzione: c'è pragmatismo e poi c'è pragmatismo. Il buon pragmatismo è se trovi una soluzione rapida ma solida, ben fondata per un problema. Cioè, eviti di progettare cose in modo eccessivo, ma le cose che realizzi effettivamente sono ancora ben ponderate. Il cattivo pragmatismo è quando si incide semplicemente qualcosa insieme che funziona "proprio così" e si romperà alla prima occasione.

Fallisci velocemente, fallisci duramente

In caso di dubbio, fallisci velocemente e fallisci duramente.

Ciò significa, tra l'altro, che il codice rileva la condizione di errore, non l'ambiente.

In questo esempio, il minimo che puoi fare è farlo in modo che l'errore di runtime duro ("profondità dello stack superata" o qualcosa del genere) non si verifichi, sostituendolo con una tua eccezionale eccezione. Ad esempio, potresti avere un contatore globale e decidere arbitrariamente di salvare dopo 1000 video (o qualsiasi numero sia abbastanza alto da non essere mai presente in un normale utilizzo e abbastanza basso da funzionare ancora nella maggior parte dei browser). Quindi dare a quell'eccezione (che può essere un'eccezione generica, ad esempio un RuntimeExceptionin Java, o una semplice stringa in JavaScript o Ruby) un messaggio significativo. Non è necessario andare al punto di creare un nuovo tipo di eccezioni o qualunque cosa tu faccia nel tuo particolare linguaggio di programmazione.

In questo modo, hai

• ... ha documentato il problema all'interno del codice.
• ... lo ha reso un problema deterministico. Voi sapete che il vostro eccezione accadrà. Non sei per il capriccio dei cambiamenti nella tecnologia del browser sottostante (pensa non solo al browser del PC, ma anche a smartphone, tablet o tecnologia futura).
• ... ha reso facile ripararlo quando alla fine è necessario ripararlo. La fonte del problema è evidenziata dal tuo messaggio, otterrai un backtrack significativo e tutto il resto.
• ... non hai perso tempo a fare la gestione "reale" dell'errore (ricorda, non ti aspetti mai che si verifichi l'errore).

La mia convenzione è quella di aggiungere un prefisso a tali messaggi di errore con la parola "Paranoia:". Questo è un chiaro segnale per me e per tutti gli altri che non mi aspetto mai che l'errore si ripeta. Posso chiaramente separarli da "reali" eccezioni. Se ne vedo uno simile in una GUI o in un file di registro, so per certo che ho un serio problema, dopo tutto non mi sarei mai aspettato che si verificassero. A questo punto vado in modalità crunch (con una buona possibilità di risolverlo rapidamente e piuttosto facilmente, poiché so esattamente dove si è verificato il problema, salvandomi da un sacco di debug spurio).

Dice un post-it sulla scrivania di uno sviluppatore senior nel mio posto di lavoro

Aiuta qualcuno?

Penso che sia spesso un buon punto di partenza per il processo di pensiero. Ci sono sempre molte cose da correggere e migliorare, ma quanto valore stai aggiungendo? ... che si tratti di usabilità, affidabilità, manutenibilità, leggibilità, prestazioni ... o qualsiasi altro aspetto.

Mi vengono in mente tre cose:

In primo luogo , l'impatto di un bug identificato deve essere approfondito prima che la decisione di lasciare il bug nel codice possa essere presa in modo responsabile. (Nel tuo esempio ho subito pensato alla perdita di memoria rappresentata dallo stack in continua crescita e che potrebbe rendere il tuo browser sempre più lento ad ogni ricorsione.) Questa indagine approfondita spesso richiede più tempo rispetto alla correzione del bug, quindi preferirei correggere il bug nella maggior parte dei casi.

In secondo luogo , i bug hanno la tendenza ad avere un impatto maggiore di quanto si pensi all'inizio. Conosciamo tutti bene il codice di lavoro perché questo è il caso "normale". I bug d'altra parte sono una "eccezione". Naturalmente, tutti abbiamo visto molti bug, ma nel complesso abbiamo visto molto più codice funzionante. Abbiamo quindi più esperienza con il comportamento del codice funzionante che con il comportamento del codice errato. Ci sono milioni di libri sul codice di lavoro e su cosa farà in quali situazioni. Non ci sono quasi nessuno sul comportamento del codice buggy.

Il motivo è semplice: i bug non sono ordine ma caos . Spesso hanno una traccia di ordine (o viceversa: non distruggono completamente l'ordine), ma la loro natura errata è una distruzione dell'ordine che il programmatore voleva. Il caos stesso tende a sfidare la stima corretta. È molto più difficile dire cosa farà un programma con un bug piuttosto che cosa farà un programma corretto solo perché non si adatta più ai nostri schemi mentali.

In terzo luogo , il tuo esempio conteneva l'aspetto che la correzione del bug significherebbe dover riprogettare il programma. (Se elimini questo aspetto, la risposta è semplice: correggi il bug, non dovrebbe richiedere troppo tempo perché non è necessaria alcuna riprogettazione. Altrimenti :) In tal caso, perderei la fiducia nel programma nel modo in cui è attualmente progettato. La riprogettazione sarebbe un modo per ripristinare quella fiducia.

Detto questo , i programmi sono cose che le persone usano e una caratteristica mancante o un secondo bug davvero ingombrante altrove può avere la priorità sulla correzione del tuo bug. Ovviamente quindi prendi la strada pragmatica e fai prima altre cose. Ma non dimenticare mai che una prima rapida stima dell'impatto di un bug può essere completamente errata.

Bassa probabilità / Conseguenze lievi = Correzione di priorità bassa

• Se la probabilità di ricorrenza è molto bassa
• Se le conseguenze dell'occorrenza sono lievi
• Quindi il bug non rappresenta una minaccia, quindi non è una correzione prioritaria.

Ma questo non può diventare una stampella per sviluppatori pigri ...

• Che cosa significa "bassissima occorrenza"?
• Quali "conseguenze lievi" significano anche?

Per dichiarare che la probabilità di insorgenza è molto bassa e le conseguenze sono lievi, il team di sviluppo deve comprendere il codice, i modelli di utilizzo e la sicurezza.

La maggior parte degli sviluppatori si sorprende che le cose che in origine avrebbero dovuto non accadere mai, in realtà accadono molto

Il nostro sistema educativo non insegna molto bene la probabilità e la logica. La maggior parte delle persone, inclusa la maggior parte degli ingegneri del software, ha una logica rotta e un'intuizione di proabilità rotta. L'esperienza con problemi del mondo reale e l'esperienza con simulazioni estese sono l'unico modo che conosco per risolvere questo problema.

Affronta la tua intuizione con i dati del mondo reale

È importante creare diversi registri per poter seguire i modelli di utilizzo. Riempi il codice con affermazioni di cose che pensi non dovrebbero accadere. Sarai sorpreso che lo facciano. In questo modo sarai in grado di confrontare la tua intuizione con dati concreti e perfezionarla.

Il mio esempio di un lieve problema e una misura di controllo

In un sito di e-commerce che ho lavorato molto tempo fa, un altro programmatore ha commesso un errore: in alcune oscure condizioni il sistema ha addebitato al cliente un centesimo in meno di quanto registrato nei registri. Ho scoperto il bug perché ho creato rapporti per identificare le differenze tra i registri e i saldi dei conti per rendere il sistema contabile più resiliente. Non ho mai corretto questo errore perché la differenza era molto piccola. La differenza è stata calcolata giornalmente ed era inferiore a 2,00 USD mensili. È così che stavamo sviluppando un sistema completamente nuovo che in un anno dovrebbe sostituire quello attuale. Non ha senso deviare le risorse da un progetto potenzialmente redditizio per riparare qualcosa che costa US $ 2,00 mensili ed è stato sottoposto a una misura di controllo appropriata.

Conclusione

Sì, ci sono bug che non devono essere corretti immediatamente, che non sono abbastanza importanti per ritardare lo sviluppo di nuove funzionalità. Tuttavia, il sistema deve avere il controllo dell'ocurenza di questo bug per assicurarsi che sia piccolo perché non possiamo fidarci della nostra intuizione.

Penso che questo stia ponendo la domanda sbagliata dall'inizio.

La domanda non è "dovrei correggere questo errore o non dovrei correggere questo errore". Qualsiasi sviluppatore ha un periodo di tempo limitato. Quindi la domanda è "qual è la cosa più utile che posso fare in un'ora, o quattro ore o una settimana".

Se correggere quel bug è la cosa più utile da fare, perché migliora il software della quantità maggiore per la maggior parte delle persone, quindi correggi il bug. Se potessi apportare maggiori miglioramenti altrove, aggiungendo funzionalità mancanti alle persone o correggendo un bug più importante, fai queste altre cose. E punti bonus extra per tutto ciò che rende più efficiente il tuo sviluppo futuro.

La correzione dei bug è sempre eccessiva

Classifichiamo prima la parte del bug .

È un errore onesto , ad esempio un errore una tantum o un'ombreggiatura variabile che è sfuggita ai test? In questo caso, spero sicuramente che, oltre a "risolvere" il problema, hai anche scritto nuovi test unitari, abbia colto l'occasione per riformattare il codice vicino, dove tutto questo è utile .

Se, tuttavia, è in realtà un difetto di progettazione come nel tuo caso, dovresti rivalutare il design o, nel peggiore dei casi, disabilitare questa funzionalità.

Quindi, per favore, non provare a risolverlo .

Ovviamente potresti fare di peggio --- potresti provare la metodologia hack-on-hack . Il looping dei video è un hack (cattiva architettura e si nota una rottura). Puoi aggiungere un limite di ciclo , in modo che dopo N iterazioni (che hai testato sia inferiore al limite del browser) il ciclo termina.

Le ramificazioni sono ovvie, ora devi supportare sia il codice non funzionante che il nuovo limite del ciclo.

PS si scusa per la vista estrema.

PPS Nota sulla terminologia: non è possibile "correggere" un bug. Beh, un veterinario potrebbe forse, ma non andiamo lì ;-). I problemi vengono risolti o "risolti", mentre i bug vengono rimossi o risolti.