Annullamento di "correzioni"

Dato che il codice sorgente è nel controllo del codice sorgente come git, hai un controllo abbastanza preciso sulle varie versioni del tuo software. Quindi hai a disposizione entrambe le opzioni.

Quello che fai in pratica dipende dal bug. Diciamo che hai un sito di e-commerce e il bug è, quando compro due articoli non aggiunge il prezzo del secondo.

Guardi il codice e vedi un errore nell'oggetto cestino, non si moltiplica per la quantità, quindi lo aggiungi e sembra che risolva il problema.

Ma poi il giorno dopo ottieni un altro bug report, quando aggiungi calze ti addebita per due coppie. ti rendi conto che la quantità di calzini è 2 quando acquisti una singola coppia e la tua correzione non funziona per i calzini.

Quindi, ora hai una scelta, cambia il codice in modo che le coppie abbiano la quantità 1 e mantengano la correzione originale in posizione. Oppure, sostituisci il codice di calcolo con qualcosa di più complicato che controlla le coppie.

Cambiare la quantità potrebbe avere ogni sorta di ripercussione. Non vuoi scherzare, anche se sembra pazzesco contare le coppie come 2 cose.

Inoltre, se non fossi lo sviluppatore che ha inserito la parola "moltiplica per quantità", beh, non sai davvero se è sbagliato o giusto. Probabilmente devi solo aggiungere una brutta correzione al codice, 'se l'articolo è una coppia, dividi la quantità per 2 prima di moltiplicarla'. Sembra male, ma in molti casi è la cosa migliore da fare.

Con le app in diretta devi soppesare il rischio di rompere le cose rispetto all'eleganza della soluzione. Spesso il cambiamento più rapido e minimo è economicamente corretto.

Questo è il motivo per cui i test automatici sono così importanti. Se hai fiducia che non hai rotto nulla, allora sei in grado di scrivere un codice migliore. Perché puoi refactoring di più per lo stesso livello di rischio.

Is keeping them more likely backfire later, as you may have broken something else, or are you more likely to have spotted other areas of a program that needed to be changed?

Se i programmatori sanno cosa stanno facendo, sperano che sappiano quali sono i tentativi precedenti per il programma. Ciò dovrebbe consentire loro di valutare se si tratta di miglioramenti o "hack", che a loro volta dovrebbero consentire loro di decidere se mantenere o rimuovere.

Ovviamente potrebbero esserci cambiamenti "neutrali" e in quei casi sospetto che la strategia di test possa dire cosa succede; se gli altri cambiamenti avranno bisogno di un lavoro extra senza evidenti benefici immediati, allora probabilmente andranno.

Onestamente, è davvero solo situazionale. Supponiamo che tu crei una correzione di bug che risolva un problema, ma qualcosa di ancora più grande si verifica. Forse scoprirai che il bug fix che hai già fatto può essere espanso, essendo il modo migliore per affrontare la fonte del problema. Forse quella correzione causerà più errori.

È solo una questione di esperienza alla fine (ho imparato nel modo più duro). Più progetti lavori e più situazioni ti capitano, più imparerai quale scelta fare.

Non dovresti mai eseguire una modifica se non sei sicuro di avere la correzione corretta. Se non sei sicuro di avere la correzione corretta, non aggiustare nulla. È sempre meglio isolare i tuoi commit, i changeset, quelli che hai nel tuo sistema di gestione della configurazione, solo alle modifiche necessarie per la correzione. Altre "correzioni" (altri bug) possono essere eseguite in un commit separato.

Se ti accorgi di avere questo problema, probabilmente dovresti dedicare più tempo ad analizzare il problema e meno tempo a eseguire il codice nel debugger.