Sto parlando di modificare un metodo lungo centinaia o migliaia di righe di codice non coperte da test.
Quando la modifica è UNA NUOVA FUNZIONALITA' DA AGGIUNGERE cioè che non modifica comportamenti esistenti il punto è quello di non peggiorare ancora la lunghezza del metodo e di testare almeno la nuova funzionalità che si implementa.
L'idea è implementare la nuova funzionalità in un altro metodo e di richiamarlo dal metodo già troppo lungo. In questo modo il metodo originale si allunga solo di una riga. Per rendere testabile il nuovo metodo serve renderlo indipendente dal contesto passandogli le informazioni che gli servono come parametri. Questo pattern si chiama Sprout Method.
Tra il metodo originale e quello nuovo ora c'è una dipendenza temporale (vedi Cohesion sul wiki). Quando il nuovo metodo viene richiamato all'inizio o alla fine del metodo originale si può applicare il pattern Wrap Method: il risultato è qualcosa del tipo void LongFoo() { NewBar(); WrapedLongFoo(); } con dei nomi migliori però :D
Quando la classe dove si trova il metodo lungo è difficile da istanziare a causa delle dipendenze è un problema per testare il nuovo metodo (Sprout o Wrap che sia) si può spostare il nuovo metodo in una nuova classe, questo pattern si chiama Sprout Class e il corrispondente per il Wrap Method è il pattern Wrap Class che è il PatternDecorator.
Il metodo lungo resta intatto e alla prossima modifica sarà necessario ancora ripetere lo sforzo di capirlo e maneggiarlo con estrema cautela.
Riferimenti: Working Effectively with legacy code di M.C.Feathers
Tags : Team Work | Agile | Pratiche | Progettazione Software |