Primo meeting dell'anno e secondo meeting in quel di Reply che ringraziamo per l'ospitalità (nd.Gabriele: questa volta sono arrivato in orario, la strada l'ho imparata, anche se stavo prendendo ancora il 16 a posto del 24, ne sono arrivate due di fila e ci stavo per cascare... un'altra volta...)

Anno nuovo, nuova attività: per la prima volta abbiamo "virtualmente" partecipato ad un refactoring challenge, lo scopo non è stato quello di partecipare realmente, ma quello di applicare qualche mossa di refactoring in gruppo per cercare di condividere con gli altri il proprio modo di applicare questa pratica. Lo abbiamo fatto con l'ausilio del proiettore, un po' perchè l'esercizio era codificato in C# e solo Roberto aveva installato l'ambiente di sviluppo necessario e possedeva le necessarie competenze, un po' per provare ad utilizzare all'interno del gruppo un modello di comunicazione uno/due-a-molti

In breve lo scopo dell'esercizio è quello di eliminare tutte le puzze dal codice che viene dato, senza rompere i test unitari, con la possibilità di aggiungere nuovo codice, sia di progetto che di test. Siamo partiti leggendo i test unitari che ci sono sembrati subito un po' scarni, Matteo era quello che brontolava più di tutti, le critiche sono state:

• Per ogni funzionalità è stato fatto soltanto un test per "l'happy path" (ovvero per un caso di utilizzo senza errori) e uno test per una condizione d'errore, molti corner case (dove sono soliti nascondersi i bug) non sono stati testati
• La parte del codice preposta all'invio di mail, non è stata mockata, ma non è stata proprio implementata, e il poco codice esistente (check dei parametri) non è stato testato

Ci siamo dati un'ora come limite di tempo per effettuare il refactoring del codice, dopodichè avremmo confrontato la nostra (parziale) soluzione con quella vincitrice del concorso. Durante la fase di refactoring c'è stato uno scambio di opinioni sui gusti/pro/contro di alcuni passi di refactoring che hanno arricchito l'esperienza ma ci hanno fatto rallentare un po', alcuni di questi sono stati:

• Passi brevi senza possibilmente rompere i test o rompendone il meno possibile
• Testare una classe che viene estratta da un'altra classe (Extract Class) che già ha dei test unitari
• Duplicare un ciclo se al suo interno vengono compiute attività di tipo diverso (Split Loop), il problema è decidere se il codice in questo modo si complica o si semplifica
• Visual studio perde decisamente nei confronti di Eclipse :-)

Alla fine del nostro lavoro ci siamo confrontati con la soluzione e abbiamo notato che

• Tutto quello che abbiamo fatto noi era presente anche nella soluzione :-)
• Ci ha lasciati un po' perplessi il metodo IsHomebrewOrderPurchasedInPastSixMonths, in quanto non incapsula la logica di business ma abbrevia solamente l'espressione booleana, meglio sarebbe stato un metodo del tipo ShouldBeMailed (si trattava di decidere se mandare una mail o meno) all'interno della classe Customer

Ecco la foto dei "giovani rivoluzionari" che hanno partecipato alla serata (tranne Fabio che sta scattando la foto)

Come potete vedere dalla foto, grazie a Fabio (ultimo ragazzo sulla destra) abbiamo ripreso il nostro meeting! Quando disponibile pubblichero' il link al prezioso filmato :-)

Per concludere la serata ci siamo gustati della buona cucina messicana :-)