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

Dato un piccolo progetto che mira ad aggiungere nuove funzionalità all'applicazione, le modifiche introdotte toccano un po 'di codice esistente, comportando l'aggiornamento di questi in determinate aree. Durante l'implementazione, ho trovato alcuni di questi codici che sono stati aggiornati hanno candidati per il refactoring.

È questo un momento appropriato per il refactoring che a sua volta richiederebbe un test di regressione per quei componenti interessati (introducendo quindi possibilmente un ambito non originariamente parte del progetto)? O dovrei rimandare, completare la funzionalità e forse avere un progetto separato per il refactoring (anche se sono un po 'titubante in quanto gli utenti aziendali potrebbero non sponsorizzare completamente un progetto che non aggiunge alcuna funzionalità, a meno che non apprezzino la manutenibilità del codice ...)?

Assolutamente.

Il refactoring dovrebbe essere eseguito su un progetto funzionante e "di passaggio". Quando tutti i test (a livello di unità, sistema e accettazione) superano, si sa che il prodotto soddisfa i requisiti. Quando si esegue il refactoring, è possibile continuare a confermare che tutti i test continuano a passare. Se un test inizia a fallire, hai fatto qualcosa di sbagliato e devi correggerlo. Se i test falliscono, è necessario correggerli prima del refactoring in modo da poter sempre assicurarsi che il refactoring non cambi la funzionalità del sistema.

Questo è anche un momento perfetto per il refactoring, supponendo che tu abbia il tempo e le risorse per eseguire il refactoring e consegnare comunque in tempo e budget. Il refactoring ora renderà più semplice la comprensione e la manutenzione del sistema, quindi quando si aggiungono ancora più nuove funzionalità, diventa più facile. Devi combattere il marciume del codice e l'entropia del software .

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

Lei menziona il cliente che non vede valore nel refactoring. In genere, al cliente non interessa la qualità del codice, ma del prodotto. Il refactoring renderà più semplice il mantenimento di un'alta qualità del prodotto e continuerà a fornire un prodotto che soddisfi le mutevoli esigenze del cliente. Prova a negoziare il tempo per il refactoring nel tuo programma (il cliente desidera funzionalità X in Y giorni, prova a vedere se non riesci a ottenere giorni Y + Z o funzionalità XN in modo da poter dedicare tempo alla progettazione, al refactoring e all'implementazione), se può.

Prendi in considerazione di rispondere alle domande seguenti, 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-Esiste un reclamo del cliente per questo codice?

1-È necessario per la funzionalità dell'applicazione

2-Il codice attuale è dannoso?

3-Vale la pena il costo del cambiamento?

4-Potresti permetterti il ​​costo?

5-È questo il miglior utilizzo delle tue capacità nell'organizzazione?

6-Le tue modifiche richiederebbero al tuo utente di reinstallare la nuova modifica - Potresti giustificarlo al cliente?

7-Potresti tollerare il rischio di una correzione errata?

8-La modifica influisce su un altro codice esterno al progetto?

9-È un prodotto in evoluzione o stabile? Se si sta evolvendo, potresti includere le modifiche con la prossima versione?

Refactor presto, refactor spesso.

Se te lo puoi permettere (tempo, denaro, ecc.) Dovresti farlo.

Lo dico perché a volte potresti rimanere senza tempo, o come dici di non ottenere soldi per un intervento di manutenzione del codice, o vuoi completare il tuo progetto il più presto possibile, e più in generale perché il refactoring ha bisogno 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 dimenticare con un sistema di controllo della versione che puoi effettivamente convertire il tuo progetto in un nuovo ramo, quindi non influenzerai affatto il tuo codice attuale.

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

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

È necessario disporre di una serie di test: test unitari automatici o test di regressione che è possibile eseguire per dimostrare 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à, lo lascerei da solo. Stai introducendo un cambiamento per motivi di cambiamento.

Sembra che il refactoring del codice renderà più semplice l'aggiunta di nuove funzionalità; questa è la teoria. Includilo nel campo di applicazione delle nuove funzionalità. È più probabile che tu ottenga il buy-in dagli utenti aziendali in questo modo. In questo caso, dovresti essere in grado di fare una discussione convincente e giustificare il tempo per il refactoring. Spero che capiranno che questa è una parte necessaria del processo di sviluppo e avranno meno obiezioni. Potrebbe non essere sempre possibile dimostrare questo vantaggio diretto.