Dovresti correggere difetti preesistenti mentre lavori su qualcos'altro?

Enigma: durante il lavoro su una nuova funzionalità o la correzione di un difetto, si riscontra un problema legacy nel codice. Cosa dovresti fare Risolvilo e rischia di alterare il comportamento del codice. O ha funzionato fino ad ora da qualche colpo di fortuna, oppure il difetto non è stato rilevato o non vale la pena che il tempo di nessuno di segnalare. Dovresti lasciarlo solo e consentire al problema di rendere più difficile il funzionamento del codice in un secondo momento? Risolvere il problema aumenterà solo il tempo dell'attività originale e ti costringerà al test di regressione. Pochi apprezzeranno il lavoro. Risolvere il problema, tuttavia, sembra giusto in qualche modo. Il codice con un minor numero di problemi è più facile da riformattare e sviluppare.

Mi trovo in questa situazione più e più volte mentre lavoriamo per modernizzare un'applicazione web. Non so dire se sono ossessivo o onorevole quando vado fuori tangente lavorando su questi vecchi bug. Come gestite queste situazioni?

Grazie Corey

Lavoro in un team molto piccolo, quindi dipende dal cambiamento:

Se si tratta di una piccola, ovvia correzione di bug, ci provo sicuramente. Aggiungo anche commenti extra se devo elaborare il codice di qualcun altro e altri piccoli miglioramenti che rientrano nella "regola boyscout" per me.

Se il codice è così intrecciato che devi chiedere "La modifica di questa interruzione è qualcosa e richiede il test" quindi no, non dovresti cambiarla. Visualizzalo nel tuo sistema di tracciamento dei bug se ti preoccupa.

Per inciso, questo è il motivo per cui provo a codificare metodi più piccoli con firme di tipo più ovvie. Se sai che non ci sono effetti collaterali e puoi far combaciare i dettagli, puoi correggere, riorganizzare o modificare qualsiasi codice interno senza rischi.

Ma non pensare che la mancanza di apprezzamento sia un motivo per non correggere i bug che trovi o per migliorare la base di codice per qualsiasi motivo. Se non altro, sei gentile con il futuro che sicuramente tornerai lì per sistemare qualcos'altro.

EDIT: devi anche guardare il tuo tempo sul progetto. Ovviamente a scadenze strette, è necessario concentrarsi sul completamento del lavoro principale, ma se si è semplicemente sotto "carico normale", penso che un po 'di pulizia qui e lì rendano tutti più felici a lungo termine.

Come sempre, dipende.

• Se è banale e sei sicuro di poterlo riparare, correggilo.
• Se ci sono molti test unitari, quindi puoi essere abbastanza sicuro di non aver rotto nulla, risolvilo.
• Altrimenti, aggiungi un // TODO, aggiungilo al tuo bug tracking, qualunque cosa

Fondamentalmente stai facendo una valutazione del rischio: qual è il rischio di cambiare rispetto a non cambiare. Se non senti di avere abbastanza esperienza (con la programmazione in generale o il sistema in particolare) chiedi a qualcun altro nel team.

Il programmatore pragmatico chiama queste "finestre rotte".

Se non risolvi le finestre rotte, c'è la tendenza a creare una spirale discendente della qualità del codice. E più di loro c'è il compito maggiore di risolverli, e quindi è meno probabile che vengano riparati.

Se risolverli ora o più tardi dipende da una questione di giudizio. È una soluzione semplice? Sei sicuro che il codice stia facendo quello che pensi che sia? È probabile che distragga dal tuo compito attuale? Sei soggetto a vincoli temporali? È probabile che introducano più bug?

Per lo meno, segna l'elemento nel tuo sistema di tracciamento e assicurati che venga riparato in seguito. È importante contrassegnarlo nel sistema di tracciamento anche se decidi di risolverlo ora, per assicurarti che sia testato e per documentare le modifiche.

Se si tratta di un bug evidente, ad esempio qualcosa che viola la sicurezza, corrompe i dati o solleva un'eccezione che viene visualizzata all'utente, correggilo. Altrimenti, chiedi a qualcuno che conosce la base di codice meglio di te.

Dipende, se è un piccolo bug in cui sei sicuro che la tua correzione abbia un basso impatto, allora personalmente la riparerei come parte dell'altro lavoro e poi lo farò sapere al PM.

Se presenta dei rischi per il cliente, gli utenti o l'azienda, presentalo al Project Manager e discuti di un corso. È il loro compito di valutare il rischio, quindi portalo alla loro attenzione e il caso di risolverlo. Quindi onora la loro decisione.

I nostri tester odiano questo. A meno che non sia molto banale, lo registriamo nel database dei bug, quindi lo assegniamo a una versione e scriviamo test di regressione. Se gli sviluppatori stanno solo apportando modifiche che non sono in programma, come è possibile mantenere una scadenza?

Sono stato in squadre in cui i difetti non critici o le violazioni standard sono presentati come un difetto "Codice debole". Direi che la persona che trova un difetto critico ha la responsabilità di lanciare una sorta di bandiera

dipende dal bug. la preoccupazione principale è l'introduzione di nuovi bug. Meglio affrontare un problema noto piuttosto che sconosciuto. Se è semplice, diciamo una modifica del testo o un semplice errore logico, lo ripariamo, altrimenti lo lasciamo solo.

Una cosa da notare, tuttavia, siamo un piccolo negozio di 4 sviluppatori e uno stagista e il bug che risolvo è probabilmente il bug che ho creato.

Se il codice è ovviamente errato, la correzione è abbastanza semplice e ritieni che il rischio di avere un impatto sugli utenti sia basso, quindi procedi. Si riduce al giudizio professionale.

Devi ricordare però che se l'hai trovato, presumibilmente gli utenti non l'hanno fatto, altrimenti l'avrebbero segnalato. Piuttosto che perdere tempo a risolvere un problema che potrebbe non essere mai riscontrato da un utente, potresti stare meglio spendendo quel tempo a risolvere i problemi che ora causano problemi ai tuoi utenti.

Prima documenta bene le osservazioni e decidi se correggerlo in seguito.

Avere una discussione formale (ad esempio, nella riunione regolare) o una discussione informale (ad esempio, durante il pranzo) con i colleghi e apportare le modifiche dopo aver acquisito maggiore fiducia sul comportamento dei codici che si intende correggere.

Sebbene ti sembri un bug / difetto, questa volta potrebbe essere una "caratteristica". Potrebbe essere una soluzione mal implementata per aggirare alcuni casi angolari all'ultimo minuto della versione precedente e la tua "correzione pulita" potrebbe far rivivere alcuni problemi precedentemente risolti.

Invertirò la tendenza qui. A meno che tu non sia nella primissima fase di sviluppo del prototipo, non dovresti mai risolverlo immediatamente, devi presentare una segnalazione di bug. Questo ha diversi vantaggi:

• il team arriva a valutarlo. È un vero bug, quali sono i rischi per risolverlo.
• la direzione decide se è abbastanza importante per avere l'impatto programmato di includerlo in questa versione
• un metodo per rilevarlo può essere aggiunto alla suite di test, si spera in modo abbastanza generale da trovare anche errori simili.
• fornisce metriche preziose su quanti bug stanno scivolando attraverso le fasi precedenti