Quali approcci posso adottare per ridurre le probabilità di introdurre nuovi bug in un'app legacy complessa?

Inizia a scrivere test per le parti su cui stai lavorando. Puoi provare un flusso di lavoro simile a questo:

1. Scrivi test per la parte che stai per cambiare. Questo ti aiuterà anche a capire come si comporta il codice esistente.
   • Codice di refactoring per supportare i test, se necessario, ma potresti voler scrivere test non unitari se il tempo è breve.
2. Esegui i test per assicurarti che le cose funzionino come previsto.
3. Apporta le tue modifiche. Refactor se necessario nello spirito del miglioramento continuo del codice, ma non farti trasportare.
4. Riesegui i test per assicurarti di mantenere la stessa funzionalità.

Se non butti via i test, nel tempo costruisci una suite di test che dovrebbe coprire le parti più importanti (e / o volatili) dell'applicazione e apportare modifiche al suo interno diventerà più facile e più sicuro.

Potresti anche trovare Lavorare efficacemente con il codice legacy di Michael Feathers utile.

Mi piace seguire Uncle Bob Martin 's regola Scout Boy :

"Quando hai un grosso pasticcio legacy, quello che devi fare è ... Quello che devi fare è smettere di fare i pasticci e iniziare a ripulirli.

Questo non significa che chiami i tuoi manager in una sala conferenze e dica loro che non fornirai funzionalità per i prossimi tre mesi mentre rifatti il codice. Non farlo! Piuttosto, significa che adotterai la "Regola dei Boy Scout" e controllerai ogni modulo in un po 'più pulito di quando lo hai verificato.

Dall'iterazione all'iterazione e dalla versione al rilascio, si pulirà questo sistema continuando ad aggiungere nuove funzionalità e funzionalità. Non c'è altro modo. "

Potresti spiegare al gestore che le correzioni che dovrebbero richiedere ore alla fine impiegano giorni a causa del pasticcio del codice base. Gli altri sviluppatori non vedranno alcun bisogno di refactoring se sono gli sviluppatori originali - conosceranno il sistema al suo interno, ma la direzione dovrebbe sapere che c'è un rischio se questi sviluppatori se ne vanno e prendono le loro conoscenze con loro.

Effettuare un refactoring completo di solito non è fattibile, così spesso si refactoring piccoli bit alla volta - un paio di metodi o un modulo. Diamine, se ci vogliono parecchi giorni per fare una correzione, forse puoi includere un piccolo refactoring del modulo problematico allo stesso tempo.

Hai davvero bisogno di spendere mesi per refactoring del codice? Oppure potresti refactoring il codice mentre apporti le modifiche. Quindi, ad esempio, se si determina che il metodo Foo deve essere modificato, si può cogliere l'opportunità di ridefinire il metodo Foo. E se devi superare una dozzina di altri metodi per capire che Foo è il problema, puoi lasciare dei commenti in quei metodi in modo che tu o qualcun altro in futuro si sappia cosa dovrebbe fare il codice. Naturalmente, ciò significa che c'è ancora un mucchio di codice spaghetti, ma puoi almeno spostare il codice base nella giusta direzione e renderti più facile per te stesso. Ottenere più mesi di tempo per il codice refactoring sarà una grande vendita perché significa che non stai offrendo nulla che l'utente finale desidera durante tutto questo tempo.

E creare test unitari (o, si spera, estendendo la suite di test esistente) dovrebbe rendere meno probabile che tu inavvertitamente interrompa qualcosa.

Un altro consiglio. Quando i bug si manifestano, e dopo aver applicato la benda non fermati qui!

Chiedi i cinque perché, prendi la pillola rossa e vedi quanto è profonda la tana del coniglio, e fissa la causa alla radice (e il percorso laggiù).

Si impara molto sul sistema. Aiuta ad assegnare le priorità a cosa correggere & refactoring. E dopo alcuni di questi viaggi hai delle solide "travi di supporto" per rafforzare il mucchio monolitico di spaghetti.

Puoi anche mantenere il vecchio codice in vigore fino a quando non sei assolutamente sicuro che le tue modifiche siano a prova di suono. Solo in caso di tutte le tue modifiche, quindi puoi attivarle in runtime e individuare rapidamente la posizione del nuovo bug di regressione:

// old code
...

if (!File.ReadAllText("c:\patch_control.txt").Contains("StrangeUIBugFix=0"))
{
    // new code goes here
    ...
}

// old + new code
int someValue = 
    IsEnabled("StrangeUIBugFix") ? a + b :  // new code
    a * b; // old code

Una cosa: Never change any existing code if you are not sure what effect change would have on complete application.