Il refactoring sta migliorando il codice in un modo che non influisce sulla sua funzionalità. Cioè, l'interfaccia pubblica rimane la stessa, ma potresti migliorare la formattazione del codice, gli algoritmi o i dettagli di implementazione. In alcuni casi, questo potrebbe persino cancellare una gerarchia di classi.
Poiché il comportamento del codice è lo stesso prima e dopo il refactoring, è possibile utilizzare gli stessi test di unità senza modifiche durante il refactoring. Se non hai test, scrivere i test per la parte su cui stai lavorando è il primo passo per il refactoring:
- Scrivi test unitari per l'unità su cui stai lavorando.
- Asserisci che i test hanno esito positivo con l'implementazione corrente.
- refactoring.
- Asserisci che i test hanno esito positivo con la nuova implementazione.
Potresti avere test che non testano il comportamento visibile esternamente, ma testano i dettagli di implementazione. Tali test facilitano l'individuazione di un problema, ma dovranno essere modificati durante il "refactoring" del passaggio 3. Il flusso di lavoro è:
- Progetta il refactoring. Cioè pensa a cosa cambierai e come dovrebbe funzionare in seguito.
- Riscrivi i test per verificare i nuovi dettagli di implementazione.
- Asserisci che i test falliscono con l'implementazione corrente.
- refactoring.
- Asserisci che i test hanno esito positivo con la nuova implementazione.
Se hai dei test per i dettagli di implementazione, è fondamentale separarli chiaramente dai test che testano l'interfaccia pubblica.
Questo flusso di lavoro garantisce che durante una fase di refactoring non dimenticherete una funzionalità richiesta.
Come contrassegni le regioni di codice che richiedono il refactoring? Consiglio di utilizzare un commento come TODO: REFACTOR because explanation . Tali commenti potrebbero essere aggiunti durante una revisione del codice. Puoi facilmente grep per un commento di questo tipo in un codice base. Hai suggerito di modificare in throw new RefactorException() , ma ciò significa ...
- ... non è possibile utilizzare il software fino a quando non viene eseguito il refactoring. Il codice di lavoro di spedizione ora può essere migliore della spedizione di un codice bello domani.
- ... non puoi eseguire test mentre quelle eccezioni sono nel codice.
Il refactoring guidato dai test ti porterà anche nelle aree che necessitano di miglioramenti, ma contrariamente alle tue eccezioni ti darà la certezza che il codice si comporta allo stesso modo prima e dopo.