Quali sono i limiti del refactoring?

Question

Sto studiando le limitazioni del refactoring sul miglioramento dell'architettura software esistente e sarei interessato a sentire le tue esperienze in cui hai riscontrato che il refactoring non è abbastanza o è ancora troppo immaturo per raggiungere i tuoi obiettivi.

Answer 1

Il codice di refactoring che non ha una serie corrispondente di unit test può essere rischioso. Se il progetto ha già una suite di unit test consolidata, a condizione che tu mantenga un approccio TDD, ci dovrebbero essere pochi motivi di preoccupazione.

Answer 2

Il refactoring può essere rischioso

Il refactoring è spesso difficile perché il refactorer spesso non è la stessa persona del designer originale. Pertanto, lui o lei non hanno lo stesso background nel sistema e le decisioni che sono state alla base del design originale. Corri sempre il rischio che i bug evitati nel design originale possano insinuarsi nel nuovo design.

Ciò può essere particolarmente vero quando un membro del team nuovo o giovane, non completamente esperto di questo sistema, decide di iniettare la tecnologia o idee new-cool-wizbang in un sistema altrimenti stabile. Spesso quando i nuovi membri del team non sono ben integrati nel team e non ricevono una guida sufficiente, possono iniziare a forzare il progetto in direzioni non volute da tutto il team.

Questo è solo un rischio, tuttavia, c'è anche la possibilità che il team abbia torto e che il nuovo membro del team, se messo in carica e gli fosse permesso di fare le sue cose, farebbe davvero un serio miglioramento.

Questi problemi sorgono spesso in un team che lavora su sistemi legacy. Spesso non sono previsti miglioramenti che alterano il mondo, quindi il team è conservatore con il loro design. Il loro obiettivo è impedire l'iniezione di nuovi bug e correggere quelli vecchi con un paio di funzionalità extra inserite. Un nuovo membro del team potrebbe venire e sconvolgere il carrello delle mele insistendo sul fatto che riscrive alcuni sottosistemi del codice. Vengono creati nuovi bug e gli utenti di un prodotto abbastanza stabile sono sconvolti perché il software, da lì la prospettiva sta peggiorando.

Quindi, se il tuo obiettivo è la stabilità a lungo termine senza grandi cambiamenti di funzionalità, spesso il refactoring principale non è quello che desideri.

Se hai comunque maggiori cambiamenti di funzionalità nel luccio, disponi di una base di utenti che si aspetta che il tuo prodotto non sia ancora completamente cotto (cioè sei in una sorta di beta), quindi è una situazione molto migliore da considerare refactoring serio perché i vantaggi a lungo termine del design superiore pagheranno e avrai meno probabilità di interrompere una vasta base di utenti.

Answer 3

Non sono sicuro che la tua domanda sia valida. Stai chiedendo delle limitazioni del refactoring. Tuttavia, il refactoring comporta la riscrittura del codice. Come possono esserci limiti a ciò che riscrivi? Puoi sostituire completamente il vecchio codice nel corso di un massiccio refactoring, pezzo per pezzo. In effetti, puoi terminare il refactoring senza un singolo carattere del codice originale, anche se questo è certamente estremo. Data questa estremità estrema delle possibilità di refactoring, come puoi supporre che ci possano essere delle limitazioni? Se tutto il codice finale potrebbe essere completamente nuovo, non ci sono più limitazioni rispetto a se avessi scritto il codice finale da zero. Tuttavia, scrivere da zero lo stesso codice risultante ti dà meno basi per continuare, meno opportunità di sviluppo iterativo, e quindi devo rispondere con una contro-domanda: nessun refactoring non ha intrinsecamente una limitazione minore di qualsiasi riscrittura?

Answer 4

Non a tutti i manager piace l'idea del refactoring. Ai loro occhi, il tempo impiegato per refactoring non viene utilizzato per aggiungere nuove funzionalità. Quindi devi convincere il tuo manager che è necessario o puoi nasconderlo mentre aggiungi funzionalità.

Quindi il rischio è di impiegare troppo tempo per il refactoring.

Answer 5

Un problema con il refactoring sorge quando non puoi cambiare l'interfaccia esterna delle tue classi. In questi casi, sei molto, molto limitato su ciò che puoi refactoring.

Answer 6

Alla risposta eccellente di Kev: "Lavorare efficacemente con il codice legacy" di Michael Feathers dovrebbe essere tenuto a leggere per le persone che lavorano nell'ingegneria del software.