Apportare grandi cambiamenti in modo incrementale

Hai ragione a temere la completa riscrittura, nulla è mai più spaventoso nel mondo del refactoring. Ci sono molte strategie per abbattere la riscrittura in blocchi digeribili, e dipende da cosa c'è di sbagliato nella base di codice per cominciare. Erano spaghetti? Era intrinsecamente instabile? Oppure, in base ai servizi deprecati?

Senza capire di più sulla tua base di codice, posso offrire solo qualcosa di generico e spero che aiuti in qualche modo. Alcune cose da provare, forse, assumendo che il problema sia spaghetti poco strutturati.

1. Iniziare a disaccoppiare tutto. Prova a sradicare lo stato e le dipendenze, pezzo dopo pezzo. Questo può quasi sempre essere fatto in modo incrementale. Inoltre, dividi le funzioni e i moduli dei mostri.

2. Man mano che le cose si disaccoppiano, l'unità prova su di loro. Hai bisogno di stabilità per tutto il refactator e questa dovrebbe essere la tua linea di base.

3. Ora hai un sacco di cose piccole e indipendenti. Guarda i modelli e inizia a organizzare e ricombinare.

4. Mentre lo fai, potrebbe essere utile adottare un approccio dev agile.

Alla fine di tutto questo, potresti non avere la Ivory Tower che i sostenitori della riscrittura potrebbero sperare, ma avrai miglioramenti tangibili che probabilmente elimineranno la necessità di una completa riscrittura.

Piccolo è sempre meglio che grande!

Un approccio incrementale, dividendo l'aggiornamento in diverse piccole versioni è solitamente l'approccio migliore, anche se è un duro investimento per la gestione.

Sembra dividere il tuo progetto in: -

• aggiornamenti del codice di presentazione per abilitare le cose fantasiose, oltre all'implementazione di alcuni dei più semplici miglioramenti dell'esperienza utente (vale a dire quelli che non dipendono dalle modifiche dello schema).
• abilitazione dell'upgrade dello schema di aggiornamento. Aggiornare lo schema, oltre alle modifiche tecniche nei programmi per gestire il nuovo schema, ma solo le modifiche della logica di business sono richieste in modo assoluto dal nuovo schema.
• cambia alla tua logica aziendale per sfruttare appieno il nuovo schema.
• infine, l'esperienza utente completa avanzata

Trovo che separare i rilasci in versioni tecniche / abilitanti, seguiti da una versione separata per le modifiche della logica di business, mantiene ogni rilascio controllato, focalizzato e il più piccolo possibile. Con conseguente sviluppo più rapido e meno errori.

Inizia in piccolo. Suggerirei un approccio incrementale con il seguente approccio:

• Scegli una parte del sistema, preferibilmente quella che ha più bisogno di refactoring.
• Ottieni questa parte del sistema sottoposto a test se possibile. Altrimenti, fallo dopo che le dipendenze sono state interrotte.
• Avvia refactoring questa parte del sistema con interruzione delle dipendenze .
• Verifica che le tue modifiche funzionino come previsto attraverso i test.
• Ripeti.

Michael Feathers ha un ottimo libro su questo argomento chiamato Funzionante in modo efficace con il codice legacy . Lo consiglio. Per ulteriore assistenza quando si tratta di rompere le dipendenze nel codice, prova a consultare il metodo Mikado .