Riunione del 17 ottobre 2007

Ci siamo trovati in Reply; alle 19:20 circa abbiamo cominciato la riunione. L'idea era: ciascuno porti un pezzettino di esperienza su refactoring.

TODO ciascuno riassuma quello che ha detto...

Matteo: ho insistito sull'importanza di scrivere test prima di fare refactoring. Il mio pattern preferito è quello degli object-oriented seams di Michael Feathers: modificare il comportamento di una classe per renderla più testabile senza toccare il codice della classe. Sembra magia ma è facile :) Alla domanda: la situazione più difficile di codice legacy in cui ti sei trovato, rispondo: è dura quando non c'è altra maniera di testare il sistema legacy che non sia interattivamente. In realtà anche nei casi in cui sembra impossibile la maniera di scrivere i test si trova; basta identificare un punto utile all'interno delle viscere del codice legacy e attaccare quello. Altrimenti è troppo facile lasciarsi andare al test sempre e solo interattivo (che non è un vero test!!!)

Alle 21:20 circa abbiamo levato le tende verso l'ottimo ristorante finto-messicano. Consiglio la fajita: è il mio piatto tex-mex preferito!

Tommaso (per fortuna il browser aveva memorizzato la password) :

• particolare attenzione va posta sui test dopo che si fa estrazione di nuovi oggetti. Spesso infatti ci si accontenta di aver testato la parte estratta 'indirettamente'. Eppure il test della parte estratta sarà sempre piu semplice da scrivere.
• probabilmente il miglior modo di imparare le mosse di refactoring e' farle a mano , senza l'ausilio di tool (Matteo non era d'accordo)
• l' abitudine all' uso di iteratori esterni obbliga a pensare per funzionalità, evitando di dover eseguire piu operazioni scorrelate all'interno di uno stesso ciclo.

Ci siamo confrontati sulle maggiori difficoltà incontrare nel praticare il refactoring. I casi piu difficili sono nel legacy code e in sistemi che usano molti thread.