Refactoring

Durante il refactoring è opportuno rispettare le seguenti regole:

• le modifiche al codice non devono modificare le funzionalità: il refactoring DEVE essere invisibile al cliente;
• non possono essere inseriti test aggiuntivi rispetto alla fase verde appena raggiunta.

Se la fase di refactoring sta richiedendo troppo tempo allora è possibile fare rollback all’ultima versione verde e pianificare meglio l’attività di refactoring, per esempio scomponendolo in più step. Vale la regola del “do it twice”: il secondo approccio a un problema è solitamente più veloce e migliore.

Motivazioni

Spesso le motivazioni dietro un refactoring sono:

• precedente design molto complesso e poco leggibile, a causa della velocità del passare ad uno scenario verde;
• preparare il design di una funzionalità che non si integra bene in quello esistente; dopo aver raggiunto uno scenario verde in una feature, è possibile che la feature successiva sia difficile da integrare. In questo caso, se il refactoring non è banale è bene fermarsi, tornare indietro e evolvere il codice per facilitare l’iterazione successiva (design for change).
• presenza di debito tecnico su lavoro fatto in precendenza, ovvero debolezze e “scorciatoie” che ostacolano notevolmente evoluzioni future: “ogni debito tecnico lo si ripaga con gli interessi”.