Dovresti refactoring il codice esistente che non è rotto in un progetto incentrato sulle nuove funzionalità?

Assolutamente.

Il refactoring dovrebbe essere fatto su un progetto funzionante e "passeggero". Quando tutti i test (a livello di unità, sistema e accettazione) passano, sai che il tuo prodotto soddisfa i requisiti. Quando si effettua il refactoring, è possibile continuare a confermare che tutti i test continuano a passare. Se qualche test inizia a fallire, allora hai fatto qualcosa di sbagliato e devi correggerlo. In caso di test falliti, è necessario correggerli prima di procedere al refactoring in modo da poter sempre garantire che il refactoring non stia cambiando la funzionalità del sistema.

Questo è anche un momento perfetto per il refactoring, presupponendo che tu abbia il tempo e le risorse per eseguire il refactoring e comunque fornire tempo e budget. Refactoring ora renderà più semplice la comprensione e la manutenzione del tuo sistema, così come aggiungi ancora più nuove funzionalità, diventa più facile. Devi combattere contro decomposizione del codice e entropia del software .

Poiché Joel Etherton indica nei commenti, devi gestire l'ambito del refactoring. Concentrati sul refactoring delle parti del sistema a cui presto aggiungerai funzionalità, eseguendo refactoring che renderanno più facile lavorare con o aggiungere le nuove funzionalità. L'uso dell'analisi statica, degli strumenti di metrica e delle revisioni del codice può aiutarti a identificare le aree più critiche. Non vuoi perdere le scadenze perché eseguivi il refactoring: devi comunque continuare ad aggiungere valore al cliente.

Dici che il cliente non vede il valore nel refactoring. In genere, il cliente non si preoccupa della qualità del codice, ma del prodotto. Il refactoring faciliterà il mantenimento di un'elevata qualità del prodotto e continuerà a fornire un prodotto in grado di soddisfare le mutevoli esigenze del cliente. Prova a negoziare il tempo necessario per eseguire il refactoring nel tuo programma (il cliente desidera funzionalità X in giorni Y, prova a vedere se non puoi ottenere i giorni Y + Z o le funzionalità XN in modo da poter dedicare tempo alla progettazione, al refactoring e all'implementazione), se possibile.

Considera di rispondere ai seguenti quesitons, quindi sarebbe facile per te prendere la decisione. La saggezza "non aggiustarlo se non è rotto" è allettante ma non sempre vera per il lavoro professionale.

0-C'è un reclamo del cliente su questo codice?

1-È necessario per la funzionalità dell'applicazione

2-Il codice attuale è dannoso?

3-Il costo del cambiamento vale la pena?

4-Potresti permetterti il costo?

5-È questo il miglior utilizzo delle tue abilità per l'organizzazione

6-Le tue modifiche richiedono all'utente di reinstallare la nuova modifica. Potresti giustificarlo al cliente?

7-Potresti tollerare il rischio di una brutta soluzione?

8-La modifica ha effetto su altri codici al di fuori del tuo progetto?

9-Si tratta di un prodotto in evoluzione o di un prodotto stabile? Se è in evoluzione potresti includere le modifiche con la prossima versione?

Refactor presto, refactor spesso.

Se puoi permettertelo (tempo, denaro, ecc.) dovresti farlo.

Dico questo perché a volte potresti finire il tempo, o come dici di non ottenere denaro per un intervento di manutenzione del codice, o se vuoi completare il tuo progetto il prima possibile, e più in generale perché il refactoring necessita di risorse. Ma a parte questo è sempre un buon momento per il refactoring.

Vuoi un codice aggiornato e se ritieni che il tuo codice abbia effettivamente bisogno di alcune modifiche, specialmente quando aggiungi nuove funzionalità, dovresti cambiarlo.

Non dimenticarti che con un sistema di controllo della versione puoi effettivamente posizionare il tuo progetto in un nuovo ramo, quindi non inciderai affatto sul tuo codice attuale.

Se il refactoring è necessario per implementare la nuova funzionalità, allora dovrebbe essere fatto e preso in considerazione come parte del nuovo sviluppo.

Avere un codice duplicato ti costerà (sia tu personalmente che la compagnia) più a lungo termine man mano che le modifiche vengono apportate a un posto e non a un altro.

È necessario disporre di una serie di test: test unitari automatizzati o test di regressione che è possibile eseguire per provare che non sono stati introdotti problemi alla funzionalità esistente.

Se il refactoring è solo un "bello da fare" - cioè non è nel codice direttamente interessato dalla nuova funzionalità, allora lo lascerei da solo. Stai introducendo una modifica per il cambiamento.

Sembra che il refactoring del codice renderà più facile aggiungere nuove funzionalità; questa è la teoria. Includere questo nell'ambito delle nuove funzionalità. È più probabile che tu ottenga un buy-in dagli utenti aziendali in questo modo. In questo caso, dovresti essere in grado di formulare una argomentazione di compeling e giustificare il tempo per il refactoring. Spero che capiranno che questa è una parte necessaria del processo di sviluppo e avrà meno obiezioni. Potresti non essere sempre in grado di dimostrare questo vantaggio diretto.