Gabriele Lana

Negli ultimi giorni, parlando alcune persone, ho notato qualcosa che non mi piace affatto e ho pensato di scrivere questo post per chiarire come la penso. Apparentemente esiste la credenza che l’apprendimento della pratica del refactoring, o più in generale del TDD (che di fatto implica il refactoring), sostituisca lo studio del Design del software in quanto (come da definizione) “applicare il TDD significa fare continuamente Design”. Discorsi come questi mi mettono un po’ di paura.

“Cos’è, e come viene usato il refatoring?” Dato il codice di un’applicazione e conoscendo la prossima funzionalità che dovrà essere implementata, posso domandarmi “Il Design della mia applicazione è adatto ad accogliere l’implementazione della prossima funzionalità? Con la conoscenza che ho oggi della mia applicazione e del dominio del problema, posso migliorarne il Design?” Rispondendo a queste domande identifico il Design che vorrei che la mia applicazione avesse e grazie al refactoring, sarò in grado di pianificare in piccoli passi il passaggio dal Design attuale a quello ideale, dopodichè sarò pronto ad implementare la funzionalità richiesta. Applicando il TDD questo ciclo (requirement/design/refactoring/test/coding/) diventa molto più frequente (da pochi minuti a pochi secondi), ma il discorso non cambia.

Non so se avete notato, ma per applicare questa pratica è necessario:

• Saper identificare il Design attuale leggendo il codice
• Saper individuare, non solo i bad smell banali quali il “Long Method” o “Large Class”, ma anche quelli per cui occorre una visione più ad alto livello dell’applicazione, come: “Speculative Generality”, “Divergent Change”, “Shotgun Surgery”, ecc…
• Saper indicare quale Design migliorerebbe quello attuale

Ovvero è necessario:

• Conoscere il Design del software: pattern, principi, idiomi ecc… (alcuni strettamente dipendenti dal linguaggio utilizzato)
• Imparare a leggere il codice sorgente di un’applicazione. Qualcuno potrebbe darlo per scontato, ma non lo è. Pensate agli scrittori di libri e a quanto mediamente leggono: leggono per imparare, leggono per farsi ispirare, leggono per poter trovare la propria identità letteraria come fusione fra gli stili appresi e la propria personalità. Voi quanto buon codice leggete?
• Conoscere e saper identificare i bad smell
• Conoscere e saper applicare i passi di refactoring per poterli eliminare

Tutto questo per dire che l’applicazione della sola pratica del refactoring non giustifica in alcun modo un’ignoranza nel campo del Design del software. Il refactoring è solo una tecnica che ci permette di raggiungere un determinato Design in maniera incrementale, requisito dopo requisito, in modo da avere in ogni momento il miglior Design possibile per le funzionalità attualmente implementate. In pratica il design di oggi è frutto di un BDUF dilazionato durante tutto il progetto, ma la parte di design Design c’è, e deve essere studiata!

Vedo già qualcuno che salta in piedi dicendo “Allora è vero, solo i programmatori preparati possono applicare le metodologie Agili!” A questa frase replico con un estratto da questo intervento di Ken Schwaber

SCRUM works with idiots. You can take a group of idiots tha maybe even didn’t go to school, don’t understand computer science, don’t understand software, engineering techniques, hate each other, don’t understand business domain, have lousy engineering tools and uniformly they will produce crap every increment

UPDATE: Neanche a farlo apposta, oggi (18/07/2007) su InfoQ Amr Elssamadisy ha espresso le stesse perplessità, James Shore ha subito replicato