Dovresti correggere i difetti preesistenti mentre lavori su qualcos'altro?

Lavoro su una squadra molto piccola, quindi dipende da cosa è la modifica:

Se si tratta di una piccola, ovvia correzione di un bug, ci proverò sicuramente. Inserisco anche commenti extra se devo lavorare attraverso il codice di qualcun altro e altri piccoli miglioramenti che rientrano nella "regola del boyscout".

Se il codice è così intrecciato che devi chiedere "Cambiando questa interruzione qualcosa e richiede un test" allora no, non dovresti cambiarlo. Portalo nel tuo sistema di tracciamento dei bug se ti preoccupa.

Questo, per inciso, è il motivo per cui provo a codificare metodi più piccoli con firme di testo più evidenti. Se sai che non ci sono effetti collaterali e puoi abbinare i dettagli, puoi correggere, riorganizzare o modificare qualsiasi codice interno senza rischi.

Ma non mi sento come la mancanza di apprezzamento è un motivo per non correggere bug che trovi o per migliorare la base di codice per qualsiasi motivo. Se non altro, sei gentile con il futuro, tu che sicuramente tornerai lì per aggiustare qualcos'altro.

EDIT: Hai anche bisogno di guardare il tuo tempo sul progetto. Ovviamente, in tempi ristretti, è necessario concentrarsi sull'ottenere il lavoro principale, ma se si è appena sotto "carico normale", allora penso che un po 'di pulizia qua e là renda tutti più felici a lungo termine.

Come sempre, dipende.

• Se è banale e sei sicuro di poterlo aggiustare, correggilo.
• Se ci sono molti test unitari, puoi essere abbastanza sicuro di non aver infranto nulla, correggerlo.
• Altrimenti, aggiungi un // TODO, aggiungilo al bug tracking, qualunque sia

Fondamentalmente stai facendo una valutazione del rischio: qual è il rischio di cambiare vs non cambiare. Se non ti 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 si risolvono le finestre rotte, si tende a creare una spirale discendente della qualità del codice. E più c'è il compito più grande di risolverli, e quindi è meno probabile che vengano riparati.

Se risolverli ora o più tardi è una questione di giudizio. È una soluzione semplice? Sei sicuro che il codice stia facendo quello che pensi sia? È probabile che distragga dal tuo compito attuale? Sei sotto vincoli di tempo? È probabile che introduca più bug?

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

Se si tratta di un bug ovvio, ad esempio qualcosa che viola la sicurezza, danneggia i dati o genera un'eccezione che viene visualizzata all'utente, quindi correggila. Altrimenti, chiedi a qualcuno che conosce il codebase meglio di te.

Dipende, se è un piccolo bug in cui si è certi che la propria correzione ha un impatto ridotto, personalmente la risolverei come parte di un altro lavoro e poi far sapere al PM.

Se ha qualsiasi rischio per il cliente, gli utenti o la compagnia lo presentano con il Project Manager e discutono un corso in avanti. Il loro compito è quello di valutare i rischi, quindi portali alla loro attenzione e il caso per risolverli. Quindi onora la loro decisione.

I nostri tester lo odiano. A meno che non sia banale, lo registriamo nel database dei bug, quindi lo assegniamo a un rilascio e scriviamo i test di regressione. Se gli sviluppatori stanno per apportare modifiche che non sono in programma, come si può mai mantenere una scadenza?

Sono stato in team 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 qualche tipo di bandiera

dipende dal bug. la preoccupazione principale è l'introduzione di nuovi bug. Meglio trattare con un problema noto piuttosto che uno sconosciuto. Se è semplice, diciamo un cambio di testo o un semplice errore logico, lo aggiustiamo, altrimenti lasciamo stare.

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

Se il codice è ovviamente sbagliato, la correzione è abbastanza semplice e ritieni che il rischio di impatto sugli utenti sia basso, quindi fallo. Dipende dal giudizio professionale.

Devi ricordare però che se lo hai trovato, presumibilmente gli utenti non lo hanno fatto, altrimenti lo avrebbero segnalato. Invece di perdere tempo a risolvere un problema che potrebbe non essere mai riscontrato da un utente, è meglio passare il tempo a risolvere i problemi che causano problemi ai tuoi utenti.

Bene documenta prima le osservazioni e decidi se aggiustarle in un secondo momento.

Avere una discussione formale (ad es. durante la riunione ordinaria) o una discussione informale (ad es. durante il pranzo) con i colleghi e apportare le modifiche dopo aver acquisito maggiore sicurezza sul comportamento dei codici che si intende risolvere.

Anche se sembra un bug / difetto per te, questa volta potrebbe essere una "caratteristica". Potrebbe essere una soluzione poco implementata per aggirare alcuni casi angolari all'ultimo minuto della versione precedente, e la tua "soluzione pulita" potrebbe rianimare alcuni problemi precedentemente risolti.

Coglierò la tendenza qui. A meno che tu non sia nella fase iniziale dello sviluppo del prototipo, non dovresti mai risolverlo immediatamente, dovresti presentare una segnalazione di errore. Questo ha diversi vantaggi:

• il team deve valutarlo. È un vero bug, quali sono i rischi di risolverlo.
• il management decide se è abbastanza importante da prendere l'impatto del programma includendolo in questa versione
• un metodo per rilevarlo può essere aggiunto alla suite di test, si spera in un modo abbastanza generale per trovare anche errori simili.
• fornisce preziose informazioni sul numero di errori che sfuggono alle fasi precedenti