Agile Day 2011

Anche quest'anno eccomi a stilare il mio personalissimo resoconto dell'Agile Day.
In primo luogo vorrei ringraziare gli organizzatori, che hanno svolto un lavoro perfetto. Se non ci siamo "accorti" di voi è perché tutto ha funzionato al meglio: bravi!
Ed ora mia una interpretazione delle sessioni a cui ho partecipato.

Back to basics: OOP and design

Il senso dell'intervento di Paolo Polce sta tutto nel titolo: dopo anni spesi a concentrarsi sul processo, abbiamo forse perso di vista i problemi tecnici, quasi fossero semplici dettagli implementativi. Scrum masters, sprints, story points, sì, vabbè, ma il codice? Beh, al codice ci penseranno le "risorse"... :-)
E' tempo di tornare a focalizzarsi sulle "risorse", ovvero sui programmatori, e sulle loro competenze, che devono costantemente essere allenate, come i muscoli di un atleta.
Come ottenere lo scopo? Con buone letture, buoni strumenti, ed un continuo esercizio volto a creare design realmente ad oggetti. Una buona architettura Object Oriented modularizza i problemi tramite gli oggetti, ed evita quindi classi "Star gate" (spesso incarnate da dei Singleton), che leggono attraverso una pioggia di getter le informazioni più disparate, collassando al loro interno l'intera logica applicativa. Occorre quindi evitare i getter, scrivendo sempre più metodi che restituiscono void. Ma come testare queste architetture? La chiave consiste nel passare da test sullo stato degli oggetti, a test che ne verificano le interazioni.

Codice legacy: usciamo dal pantano!

Bel workshop di Stefano Leli e Simone Casciaroli. I partecipanti sono stati invitati a fare refactoring su un piccolo progetto, che nella gerarchia Bird-Duck-Chicken mostra un caratteristico caso di violazione del Principio di sostituzione di Liskov, il complesso edipico irrisolto della programmazione ad oggetti.
La sessione, terminata con la presentazione della soluzione dei relatori, è stata interessante, anche se avrebbe richiesto sicuramente almeno un'altra ora per riuscire al meglio.

Lean, A3 e kaizen

Claudio Perrone nel suo intervento ha illustrato i i Kaizen Memo ed il medoto A3.
I Kaizen Memo sono piccoli fogli di carta da appendere su una parete per dare evidenza ai miglioramenti raggiunti nel processo produttivo. Dovrebbero riportare il problema affrontato, la misura intrapresa per risolverlo e le conseguenze ottenute.
Il metodo A3 prevede di utilizzare un modulo di carta, solitamente di dimensione appunto A3, sul quale presentare in modo oggettivo:

  • la situazione corrente;
  • l'obiettivo da raggiungere (ciò definisce il problema come differenza tra situazione corrente ed obiettivo da realizzare);
  • l'analisi delle cause del problema;
  • l'elenco delle contromisure da adottare;
  • una matrice what-who-where-how per realizzare le contromisure;
  • un elenco di azioni supplementari (follow-up) da intreprendere in caso di problemi.

L'intervento è proseguito definendo la figura del manager ideale, che non dovrebbe essere né un poliziotto che punisce chi si comporta male, né una mamma che coccola i suoi figli, e neppure una figura assente. Il vero manager dovrebbe invece essere una persona che si occupa di eliminare i problemi che ostacolano il processo produttivo. La domanda che un manager dovrebbe rivolgere ai suoi sottoposti non è "cosa hai prodotto ieri", ma "quali problemi hai avuto".
Claudio Perrone ha concluso dando una bella definizione dei metodi lean/agili: strumenti per fare soldi attraverso la crescita delle persone.

Back to basics hands-on

Antonio Carpentieri e Paolo Polce hanno condotto un efficace workshop sul design ad oggetti. Utilizzando come esempio il gioco del monopoli, hanno mostrato nella pratica come realizzare software ad oggetti senza abusare di getters e favorendo composizione, basso accoppiamento ed alta coesione.
Molto importante la sottolineatura finale di Antonio Carpentieri che ha ripreso il keynote di Paolo Polce: un programmatore non può crescere lavorando solo su codice di produzione. Come un atleta non migliora solo con le partite, ma soprattutto con gli allenamenti, anche chi sviluppa software non può non allenarsi praticando i kata.

Unit Tests VS End to End Tests

Probabilmente il mio giudizio su questo intervento è falsato dalla fatica accumulata alla fine di una giornata così intensa, ma dalla presentazione di Domenico Musto non sono riuscito a trarre nessuna informazione interessante. Chiedo venia.

Conclusioni

Anche questa edizione dell'Agile Day è stata all'altezza delle aspettative. Mi è piaciuta molto l'enfasi sul codice, dopo troppo tempo speso sui problemi di processo. Grazie ancora agli organizzatori ed arrivederci al 2013!

L’apostata del TDD

Ho seguito con molto interesse la discusione generata da un post che vuole essere iconoclasta già nel titolo: l'apostata del TDD. Vorrei sottoporvi le mie annotazioni.

Perché il post mi pare interessante

Perché il post mi pare interessante? Perché tocca le corde della mia esperienza personale: anche io, come l'autore, ho provato curiosità nel notare di aver sviluppato a volte del buon codice senza l'uso del TDD e del pessimo codice con il TDD. Posto che è plausibile che problema risieda in me e non nel metodo, mi pare lecito comunque chiedersi se anche il metodo stesso non abbia qualche pecca. Provo infatti un certo fastidio quando, durante l'analisi di fallimenti del TDD (e mi pare che comunque ve ne siano), si escluda dogmaticamente che lo strumento possa avere qualche difetto. Tutto questo mi ricorda le critiche che (inutilmente) qualcuno negli anni 70 muoveva a psicanalisi e marxismo: ci si chiedeva infatti se fosse possibile che queste dottrine fossero di per sè corrette, mentre ogni loro clamorosa debacle si dovesse addebitare sempre ad una loro incorretta realizzazione, pienamente giustificabile ed interpretabile all'interno delle dottrine stesse.

Cosa non funziona nel TDD?

Ma allora cosa ci sarebbe di sbagliato nel TDD? Non so se vi sia qualcosa di "sbagliato", sicuramente indagherei su questi punti.

La visione d'insieme

Riprendendo quanto detto da Carlo Bottiglieri sulla lista extremeprogramming-it, il TDD potrebbe far perdere la visione d'insieme del problema, o anche problematiche trasversali all'intero sistema.

Cicli troppo stretti

Il TDD si basa sul "mantra" "red-green-refactor", che però, nella sua definizione, prevede di essere un ciclo di breve durata, per consentire un riscontro immediato. Ciò a mio avviso implica che la fase di refactor non possa spostare di molto l'"inerzia" del sistema: ciclo breve, refactoring breve, quindi spesso indirizzato a piccoli obiettivi. Il refactoring, inoltre, nascendo come "cura" per le puzze del codice, a risulta uno strumento di ottimizzazione locale: diminuisco la lunghezza dei metodi ed il numero di parametri, creo classi disaccoppiate, ottimizzo gli indicatori "locali" di qualità, ma la struttura generale è comprensibile e riutilizzabile?

Coesione vs accoppiamento

Durante un suo corso, Francesco Cirillo mi ha fatto riflettere su questo concetto: del buon codice deve essere ad alta coesione e a basso accoppiamento, ma vi è una tensione tra i due aspetti. Il mio dubbio è: il TDD tende a sistemi a basso accoppiamento, ma forse anche a bassa coesione?

No Big Upfront Design?

Il TDD ha viaggiato a braccetto con il concetto di "No Big Upfront Design", anche nella sua variante "non facciamo design prima di scrivere il codice, ma solo scrivendolo". Ma siamo proprio sicuri che il codice sia il l'unco luogo, o comunque quello ideale, dove disegnare il codice stesso?

Il lato oscuro dei test

Non dobbiamo dimenticare quello che Matteo Vaccari chiama "il lato oscuro dei test": paradossalmente un sistema copero al 100% da test potrebbe invitarci a scrivere codice "peggiore", in quanto, qualsiasi schifezza volessimo introdurre, avremmo sempre la certezza di non rompere nulla.

Sono anch'io un apostata?

Non so se dirmi apostata anch'io: forse non posso, non essendo mai stato un fedele praticante. ;-)
Sicuramente diffido di chi ha fatto del TDD una religione, o meglio un feticcio.
Forse, riprendendo la bella analogia di Jacopo Romei, sono nella fase "Ha – Vìola la regola" del ciclo "Shu-Ha-Ri": sto cercando di mettermi in opposizione al TDD, al fine di capirlo meglio.
Certamente vorrei saper usare il TDD come Carlo, ma a volte mi chiedo se questo non sia un tipo di programmazione che solo dei grandi virtuosi sono in grado di svolgere.
O forse sto ancora ricercando la mia via e sono ancora molto lontano anche dalla fase "Shu"...

Il sofista

E' da qualche giorno che sulla lista italiana di "Exteme programming" infuoca una polemica su cosa sia XP, chi abbia il diritto di darne una definizione e quale definizione se ne debba dare. Non so perch, ma tutte queste discussioni mi fanno tornare in mente un brano dell'Apologia di Socrate. Ecco cosa Platone fa dire a Socrate.

E se qualcuno vi ha ancora detto che io faccio leducatore e che ne ricavo gran guadagno, neppure questo vero. Riconosco certo che bello essere capace di educare gli uomini, come un Gorgia Leontino, un Prodico di Ceo, o un Ippia di Elide. A costoro concesso, o Ateniesi, di andare di citt in citt e di attirare al loro insegnamento i giovani, i quali invece potrebbero benissimo, senza spendere nulla, frequentare linsegnamento di quei concittadini che volessero scegliersi; quelli invece sanno persuaderli ad allontanarsi da questi e a venire loro, a pagarli profumatamente e a mostrare anche la dovuta gratitudine. Che dico? E venuto qui fra noi un sapiente uomo, un cittadino di Paro, come ho potuto apprendere per avere io parlato con uno che con i Sofisti ha speso pi denaro che tutti gli altri messi insieme, Callia precisamente, il figlio dIpponico. Voi sapete che egli ha due figli; ebbene io ho voluto interrogarlo:
-Callia [...] A chi dunque bene affidare [i giovani]? Chi abile a sviluppare in loro le virt proprie delluomo e del cittadino? Suppongo che tu ci abbia molto riflettuto, poich hai dei figli. C qualcuno che ne sia capace o no?
-Certamente, mi rispose.
-E chi costui, chiesi, e di quale paese , e che prezzo chiede per il suo insegnamento?
-E Evno di Paro, o Socrate, mi rispose, e chiede cinque mine.
-Felice Evno, pensai io, se veramente possiede questarte e linsegna a cos modico prezzo! Anchio mi sentirei fiero e felice se sapessi fare altrettanto; ma io non so, o Ateniesi.

Anche noi, come gli Ateniesi di oltre due millenni fa, ci troviamo nelle condizioni di dover distinguere gli insegnamenti dei sofisti da quelli dei socratici. Alcuni indizi potrebbero forse aiutarci.

  • Il sofista colui interessato pi al guadagno che alla ricerca della verit.
  • Il sofista annuncia agli altri di conoscere la verit, il socratico dichiara solo di ricercarla.
  • Il sofista vuole imporre la propria autorit, al socratico l'autorevolezza data dagli altri.

In base a questi criteri, in me molti dubbi sorgono su alcuni presunti "guru"....

Italian Agile Day 2009 - Le mie impressioni

Un altro Agile Day passato ed eccomi nuovamente a scrivere un sommario della mia esperienza.

Peter Stevens - Fixed Price Projects With Agile It can be done!

Possiamo stimare a priori tempi e costi di un progetto agile? Possiamo applicare i metodi agili quando il costo ed il tempo sono scolpiti nella pietra? Certo, sarebbe bello poter vivere in un mondo in cui tutti i contratti fossero tagliati sul concetto di iterazione, di sviluppo incrementale. Purtroppo ci sono occasioni nelle quali dobbiamo stimare i costi, nei quali dobbiamo sapere se riusciremo a rilasciare entro una certa data, magari remota. Chi, ad esempio, sviluppa il software per gestire grandi eventi come i mondiali di calcio non pu chiedere di spostare la data della finale perch lavora in un team agile e ha bisogno di una nuova iterazione per completare le storie!

Peter Stevens ritiene che lo sviluppo agile si possa adattare a queste situazioni, anzi che sia il miglior metodo da adottare. Questo perch l'unico sistema per valutare in corso d'opera la velocit alla quale lo sviluppo si sta svolgendo.


Waterfall

Per affrontare progetti di questo tipo occorre per:

  • un cliente del quale fidarsi;
  • una pianificazione che lasci "cuscinetti" liberi nei quali compensare eventuali ritardi;
  • criteri certi (e automatizzabili) per determinare quando una funzionalit conclusa;
  • criteri per stabilire l'importanza delle varie funzionalit per realizzare prima le storie pi importanti e consegnare alla fine del progetto, quando la pressione maggiore e le energie si esauriscono, le funzioni di minor rilievo;
  • un team esperto.
  • Maggiori dettagli sulla presentazione si trovano qui.

Alberto Brandolini - Possiamo fare di meglio

La presentazione mattutina di Alberto Brandolini partita da una serie di provocazioni ad effetto sui seguenti temi.

  • Spesso si rompe il rapporto di fiducia tra il software e chi lo usa, sia egli un utente finale o chi fa parte dello stesso team di sviluppo. Scatta allora il meccanismo della "complessit compensativa", cio degli strani trucchi per aggirare i comportamenti errati dei sistemi.
  • A volte gli sviluppatori accettano passivamente i requisiti che sono dati loro: ma chi d questi requisiti il vero esperto del problema, o, se lo veramente, ha avuto modo di pensare ai requisiti in maniera critica? I requisiti non sono in alcuni casi semplicemente la mummificazione di un processo che potrebbe essere invece migliorato?
  • Nei progetti software pu nascere quello che stato definito "technical debt". Brandolini suggerisce una metafora pi calzante per questa progressiva deriva nella qualit del codice: inquinamento, ovverosia un processo estremamente dannoso, difficilmente reversibile e con un tempo di riparazione incalcolabile.
  • A volte lo sviluppatore non ha abbastanza umilt per capire di dover approfondire il dominio da un punto di vista non semplicemente informatico.

Dopo aver introdotto questi spunti di discussione, Brandolni ha lasciato la parola all'uditorio. L'esito di questo esperimento di "terapia di gruppo" a mio avviso non per stato brillantissimo: purtroppo non emerso molto di interessante, se non una collezione di aneddoti sul nostro lavoro.

Pietro Brambati - ASP.NET MVC: Programming & Testing

Dato che prima del pranzo non mi sembrava vi fossero relazioni degne d'interesse, mi sono infilato nell'auletta dedicata alla presentazione dell'ambiente di test creato per .NET MVC. Io odio gli strumenti di sviluppo Microsoft!!! Questo mio sentimento nacque anni fa quando Visual Basic 6, con un fantastico "Il controllo OCX non registrato correttamente", mi fece affogare in un oceano marrone nel bel mezzo di una demo ad un centinaio di persone. Nonostante questo, mi sembrato che il supporto di Microsoft ai test unitari sia discreto e che l'oratore, molto preparato, sia riuscito a dare a i colleghi della sponda Microsoft un buon numero di informazioni utili su come scrivere codice in modo pi efficace. L'impressione comunque che con questo prodotto Microsoft stia svolgendo un diligente compitino per conquistarsi la medaglietta "agile" e la relativa fetta di sviluppatori.

Alberto Quario - Scenario testing

Questo forse stato l'intervento pi interessante della giornata. All'Agile Day si molto parlato di processi, ma ci si un poco scordati del codice. Alberto Quario ci ha riportati nel cuore del problema, citando le parole di Gerard Meszaros: I test possono diventare il collo di bottiglia dei processi agili. (Ma allora non le sparavo cos grosse quando parlavo dei test come palle al piede!). Uno dei principi da seguire per evitare che i nostri test divengano dei mostri incomprensibili, difficili da scrivere, leggere e manutenere il seguente: nel corpo del test deve andare tutto e solo quanto strettamente necessario per la sua comprensione.

Alcuni consigli sono quindi:

  • radunare in metodi dal nome esplicito (operational methods) i dettagli di inizializzazione dello scenario del test
  • se il test prevede, come nel caso si utilizzi DBUnit l'uso di file di inizializzazione, magari in XML, parametrizzarne la creazione rendendone chiaro l'intento all'interno del test

Francesco Mondora: vivere in un angolo proattivo

Francesco Mondora nel corso della sua presentazione ha detto di apprezzare eventuali riscontri da parte del pubblico. Ecco quindi il mio, che purtroppo negativo. Il tema trattato mi apparso fumoso, ed il tono ieratico utilizzato era probabilmente fuori luogo. Ma forse il problema solo mio che non sono riuscito a capire cosa si volesse comunicare...

Alberto Brandolini - Introduzione al Domain Driven Design

Ecco un'altra gran bella sessione, nella quale Brandolini ha descritto con abilit e preparazione i principi del Domain Driven Design.

Entrare nel dettaglio di quanto visto molto difficile, data la mole di informazioni trasmesse. Mi piacerebbe comunque segnalare il concetto di Bounded context, ossia il limite entro il quale il significato di un'astrazione del dominio non ambigua, o, per usare una visione pi orientata al codice, il limite di applicabilit di un gruppo di classi del sistema. Mi sono imbattuto in questo problema quando, nella mia presentazione su Scala, ho parlato di oggetti che ingrassano a dismisura. Da quanto ho capito, anche nel DDD ci si occupa di questo problema, ma da una prospettiva "sistemica": occorre definire l'ambito entro il quale opportuno riutilizzare il codice che definisce un'astrazione. All'esterno di tale ambito meno costoso riscrivere parte delle astrazioni ed accettare una certa duplicazione nei sistemi. Il tema, interessante e complesso, alla base del fallimento di grandi utopie Object Oriented come il progetto San Francisco di IBM. Anzi, a mio avviso mette in discussione tutti i miti dell'Object Orientation a partire dalla riusabilit, ma forse converr parlarne in un'altra occasione.

Conclusioni

Anche quest'anno l'Italian Agile Day non ha deluso le aspettative: relazioni quasi tutte di altissimo livello, con l'apprezzabile idea di aprire a contributi internazionali. Se proprio si vuole fare un piccolo appunto, si dovrebbe parlare di un'eccessiva enfasi posta sugli aspetti di processo a scapito delle sessioni "pratiche", anche se, come avete potuto leggere, i "puri" sviluppatori come me non hanno avuto occasione di annoiarsi.

Grazie a Marco Abis ed ai ragazzi dell'XPUG Bologna per l'enorme e riuscitissimo sforzo organizzativo.
(Ah, avete gi donato qualcosa all'Agile Day? ;-) )

RDS Kata

In questo post mostrer la mia discutibilissima soluzione allRDS Kata proposto sul blog di SI-Agile, il vivace gruppo che raccoglie gli agilisti della Svizzera Italiana. Il codice presente in questo file zip, spero a breve di creare un progetto su Google Code per ulteriori sviluppi.

Funzioni di utilit

Partiamo subito con la prima sequenza di test.
Leggendo tutti i requisiti del Kata, ho pensato fosse necessario avere in primo luogo una funzione che centrasse le stringhe secondo le specifiche. Ho pertanto creato dei test per un metodo statico center da inserire nella mitica classe di utilit StringUtils, che non pu mancare in qualsiasi progetto Java. Il primo banale test, testCenterDoesNotChangeTooLongStrings, mi servito per disegnare linterfaccia del metodo. Per scrivere i test successivi mi sorta la necessit di avere una funzione blanks, che, guarda caso, mi poi tornata utile anche nel codice di produzione. Ho deciso di non scrivere un test specifico per blanks, avendo fiducia che, una volta creata correttamente la funzione stringOf, la sua specializzazione che creasse stringhe di spazi fosse banale.
Uso qui volutamente il termine di funzione, in quanto questi metodi hanno la propriet di trasparenza referenziale, ovvero restituiscono sempre gli stessi valori a fronte dei medesimi ingressi, indipendentemente da un qualsiasi concetto di stato del sistema; inoltre non hanno alcun effetto collaterale. Se ci fosse la possibilit di utilizzare i metodi statici come parametri di altre funzioni ;-)
Concludendo le divagazioni, vorrei solo annotare che, per migliorare la leggibilit del codice e ridurre le duplicazioni, ho fatto un po di refactoring sui test estraendo il metodo assertCenterReturnsAStringOfFixedLength.

Le classi principali

Sono poi passato al disegno principale della mini applicazione tramite i test di RDSGeneratorTest che ho cercato di rendere indipendenti dal numero di caratteri del display.
Leggendo le specifiche del Kata ho cercato di elaborare una metafora: le varie parti da mostrare sul display (autore, data, titolo) sono gruppi distinti di parole, ovvero delle frasi. Ho quindi stilato i test di RDSSentenceTest, facendo anche in questo caso attenzione a rendermi indipendente dalla lunghezza del display. La prima stesura della classe RDSSentence, che comunque supera tutti i test, stata la seguente:

 
public class RDSSentence {
 
  private final String sentence;
  private final int displaySize;
 
  public RDSSentence(String sentence, int displaySize) {
    this.sentence = sentence;
    this.displaySize = displaySize;
  }
 
  public String[] tokens() {
    if ("".equals(sentence.trim())) {
      return new String[]{};
    }
 
    String[] tokens = sentence.trim().split("\\s+");
    if (tokens.length == 0) {
      return new String[]{};
    }
 
    Collection<String> result = new ArrayList<String>();
    StringBuffer accumulator = new StringBuffer();
    for (int i = 0; i < tokens.length; i++) {
       if (accumulator.length() + tokens[i].length() + 1 <= displaySize) {
         if (accumulator.length() > 0)  {
           accumulator.append(" ");
         }
         accumulator.append(tokens[i]);
       } else {
         if (accumulator.length() > 0) {
           result.add(accumulator.toString());
         }
         accumulator = new StringBuffer(tokens[i]);
       }
       if (i == tokens.length -1) {
         result.add(accumulator.toString());
       }
    }
 
    return result.toArray(new String[]{});
  }
 
}
 

Come potete vedere, il codice troppo complesso, con un numero ciclomatico molto elevato. Per un buon refactoring occorreva unaltra metafora: il display che accumula parole fino ad una certa lunghezza pu essere appunto visto come un accumulatore elettrico, o, se vogliamo, idraulico che, raggiunta la capienza, si svuota in un tubo di scarico. Sono nate cos le classi Accumulator e StringWharehouse, che non hanno test autonomi, ma vengono esercitate indirettamente dai test di RDSSentenceTest. La classe StringWharehouse, con una leggera modifica, mi poi stata utile per migliorare il MockRadioStation, che in un primo tempo accumulava i dati in un semplice StringBuffer.

Conclusioni

Cosa ho cercato di esercitare con questo Kata?

Sicuramente non ho raggiunto completamente i miei obiettivi, spero comunque di aver fatto un piccolo passo in questa direzione.

I test unitari sono una palla al piede (se non li sappiamo scrivere)

Troppo spesso i sostenitori delle metodologie agili si fanno trasportare dall'entusiasmo, e, quando cercano di convincere qualche collega ad abbracciare l'agilismo, si lasciano scappare frasi come Quando inizierai a fare i test unitari vedrai che la tua produttività aumenterà. Niente di più falso: iniziare a scrivere i test unitari abbassa drammaticamente la produttività! Per quale motivo? Ho vissuto l'esperienza sulla mia pelle, ma la chiara consapevolezza delle ragioni del fenomeno mi è arrivata quando ho collaborato alla revisione di un ottimo volume pubblicato da Manning: The art of unit testing. Questo è il primo libro che abbia letto a mettere in evidenza un fatto spesso taciuto: i test unitari hanno un costo enorme, specialmente se non vengono scritti nel modo corretto.
Il costo dei test non risiede solamente nel tempo speso per la loro scrittura, ma, come per qualsiasi pezzo di software, soprattutto nello sforzo necessario per la loro manutenzione. Vi è inoltre un'altro aspetto da considerare nell'introduzione dei test unitari: il codice deve essere scritto in modo differente, secondo un design che consenta la testabilità. Questo, però, porta generalmente ad un miglioramento netto della qualità del software, anche se potrebbe indurre qualche programmatore maldestro in inutili complicazioni.
Dunque, perché i test unitari possono divenire una palla al piede? Perchè il neofita generalmente non è in grado di scrivere test che abbiano le seguenti caratteristiche:

Affidabilità

Come dicevo, i test unitari, anche se scritti bene, anche se generati automaticamente, costano. Quelli scritti male costano enormemente di più, ma tutti hanno in ogni caso un costo, quello della loro manutenzione. Siamo comunque invogliati a pagare un prezzo anche salato quando riceviamo in cambio un beneficio maggiore. Il beneficio dei test, oltre al già citato obbligo ad elaborare un design più efficiente, consiste nella loro affidabilità, che dovrebbe rispecchiare l'affidabilità generale del nostro software. Un test dovrebbe fallire se, E SOLO SE, esiste un errore nel software di produzione. Se il test fallisce anche per altre ragioni (un baco nel test, il DB che non è stato inizializzato opportunamente, il fatto che il test funzioni solo sul sitema operativo della mia macchina e non su quello che usano i miei colleghi), allora stiamo buttando dei soldi dalla finestra. Inoltre il test dovrebbe fallire in caso di errori. E' ovviamente impossibile riuscire a scrivere un test per tutti i possibili errori, ma questo dovrebbe essere il nostro obiettivo. Scrivere il test prima del codice, per poterlo vederlo fallire, è una tecnica che ci aiuta in questo senso.

Manutenibilità

Questa è la bestia nera dei test unitari. In molti casi è già un affare raggiungere l'affidabilità, la manutenibilità è in molti casi una chimera. Si dice spesso, a ragione, che dei buoni test aiutano il cambiamento del software. Test scritti male possono essere invece un ostacolo all'evoulzione del nostro programma. Quante volte ho visto andare in barra rossa decine di test per una piccola modifica nel protocollo di comunicazione con un oggetto! Come poter raggiungere questo obiettivo?

In primo luogo con il refactoring accurato del codice di test. Rimuovere duplicazioni dai test è fondamentale per non dover cambiare manualmente tonnellate di codice alla prima modifica nel nostro design.
Un altro punto chiave è quello di cercare di non testare lo stato privato di un oggetto, ma di verificarne il funzionamento in relazione ai suoi collaboratori (trasformati in opportuni Stub o Mock). Se questo non è possibile, allora potrebbe valere la pena di estrarre il comportamento nascosto in oggetti da testare separatamente.
Si deve inoltre fare attenzione a non testare più di quanto sia necessario: l'uso eccessivo di Mock quando degli Stub potrebbero essere sufficienti può farci incorrere in questo problema.

Leggibilità

La leggibilità dei test è fondamentale. Quando va in barra rossa un test illeggibile è come quando si accende una spia sconosciuta sul cruscotto di una macchina di cui non avete il libretto di manutenzione: o andate nel panico, o fate finta di nulla incrociando le dita e sperando che tutto vada bene.
Occorre curare i nomi dei test, senza aver paura di scrivere troppe lettere. testCarrello non significa nulla, testSeAggiungoUnProdottoAlCarrelloAumentaIlTotale indica chiaramente l'intento del test. Altri accorgimenti sono estrarre fasi di inizializzazione in medodi di servizio con nomi espressivi, definire il metodo toString in modo tale che mostri valori significativi in caso di fallimento, evitare di inserire magic numbers e, anche in questo caso, refactoring, refactoring, refactoring!

Conclusioni

Quindi non dobbiamo scrivere test, dobbiamo abbandonare il Test Driven Development (TDD)? No, al contrario, dobbiamo scrivere test con sempre maggiore cura, avendo ben chiaro che i test sono come i figli: non basta farli, poi bisogna anche mantenerli!

Italian Agile Day 2009


Italian Agile Day 2009

E' stata annunciata la data per lo svolgimento del sesto Italian Agile Day: si terr il 20 novembre 2009 a Bologna. Come sempre la conferenza si annuncia interessantissima: vi dar aggiornamenti nei prossimi giorni.

Implicit conversions in Scala are cool

Andy Warhol  Dollar sign

Sometimes I hear sentences like Domain Specific Languages (DSL) can be generated effectively only using dynamic languages, or This super-cool feature could not be possible in a static typed language. More and more, some people would transmit the idea that dynamic languages are agile and cool, while static ones are rigid and old. I strongly disagree! I think that in static languages lots of unit tests are generated and maintained automatically by the compiler, while in dynamic ones the programmer should create and maintain these tests. So static languages have lots more unit tests: isn't this agile programming? And what about cool features? Well, what do you think about a language in which you can write something like this?

 
(5.0 USD) + (2.0 USD) == (7.0 USD)

Cool DSL, isn't it? Sure, and I will show you that this is possible (and very easy) using a language with a strong and static type system: Scala.

As we are going to write yet another money example, we could begin with the definition of currencies.

 
abstract class Currency {
  def name: String;
  override def toString = name
}    
 
object Euro extends Currency {
  def name ="EUR"
}    
 
object Dollar extends Currency {
  def name = "USD"
}

Not very exciting. We simply define an abstract Currency class and two singleton objects that extend this class. Note that these objects are instances of anonymous subclasses of Currency. This does matter, as we'll see in a moment.

Now let's define money.

 
case class Money[C &lt;: Currency](amount: Double, currency: C) {
  def + (otherMoney: Money[C]) = {
    new Money(amount + otherMoney.amount, currency)
  }
  override def toString = amount + " " + currency
}

Our class is parametric in the type C, and we tell to the compiler that it must be a subclass of Currency. This way we have the nice consequence that the + operator can add only money of the same currency, and this test is done by the compiler before our code is running.

It's time to get to the cool feature: implicit conversion. So, in the same file Money.scala in which we defined the Money class, we create a Money object, which has the responsibility to convert doubles, let me say, "annotated" with a currency, into Money.

 
object Money {
  implicit def doubleConverter(d: Double) = new {
    def EUR = {
      new Money(d, Euro)
    }    
 
    def USD = {
      new Money(d, Dollar)
    }
  }
}

Uhm, it sounds a bit strange. How we can use it? Let's see an example.

 
import Money._    
 
object MoneyMainProgram extends Application {    
 
  val tenDollars = (4.0 USD) + (6.0 USD)     
 
  println(tenDollars)
}

Now some explanations are required.

In the first line we import the Money object. We can see it as a kind of static import, that, among other things, adds to the scope of our code all the implicit conversions defined in that object.

When we write 4.0 USD, we try to invoke the USD method on the 4.0 object, which is a double. Obviously there isn't such a method in the Double class, but the compiler, before giving up and throwing an error, tries to see if there is some way to convert the 4.0 in an object that does understand the USD method. Luckily we have imported the doubleConverter which takes a Double and transforms it in an instance of an anonymous class with a USD method: bingo! So the compiler transforms our code in something like this:

 
  doubleConverter(4.0).USD()

But what is the result of this expression? Well, it's an instance of the Money class expressed in Dollar. This class has the + method that we can use to add another Money in the same currency. Cool!

Let's take a look to our work. We needed to add some features to the Double class. In some dynamic languages we could monkey patch this class. In Scala we did it using a dynamic conversion from Double to a class with the methods we need, so we reached the same purpose in a static and safer way.

And so, an old fashioned static language could have such cool features? It seems....

La tessera mancante

E' stata una coincidenza fortunata. Nei giorni scorsi stavo scrivendo del codice, per la prima volta da tempo del codice altamente algoritmico. Da bravo scolaretto XP, avevo creato una serie completa di test, avevo rifattorizzato estraendo metodi, rinominando variabili, abbassando il numero ciclomatico. Le classi erano piccole, i metodi corti, eppure il codice, pur funzionando egregiamente, in qualche modo mi infastidiva.
Poi alla scorsa riunione dell'XP-UG di Milano, Matteo Vaccari ha parlato brevissimamente dell'argomento, ed stato illuminante. Da qui il suo interessante post.
In particolare una frase pesa come un macigno su quanti, come me, pensano di essere agili solo perch fanno TDD (o qualche altra pratica XP):
"TDD could be a crouch that allows you to give up finding a good design and settle for a mediocre one".
Puoi fare tutto quello che dice il libro bianco di Kent Beck, ma forse non ti accorgi che c' una tessera mancante....

Quello che gli agilisti non dicono

I vantaggi dei test unitari sono ben noti a tutti: miglioramento del design, documentazione del codice, aumento della qualit tramite la diminuzione dei bachi e la possibilit di ristrutturare il codice in modo sicuro. Quello che gli agilisti (a volte) non dicono che i test unitari, pur portando tutti questi benefici, rappresentano anche un costo nel processo di sviluppo. Un primo costo banalmente rappresentato dal tempo necessario per il loro sviluppo, ma questo non l'aspetto principale del problema. L'onere principale dei test, forse pi difficile da cogliere, ci indicato proprio dalle metodologie agili: tutto il codice prodotto comporta un costo di manutenzione, anche lo stesso codice di test.
Occorre quindi saper capire quando il prezzo dei test sia ripagato dai benefici e quando no. La mia opinione che la creazione di test approfonditi per le interfacce grafiche non quasi mai "economicamente" conveniente. Riprendo qui alcuni esempi che ho portato in una discussione nata con Matteo Vaccari sulla lista dell'XP User group di Bergamo.

Qualche anno fa, penso fosse il 2003, assistetti ad una presentazione al Webbit nella quale Bruno Bossola mostr come fosse possibile applicare il TDD alla realizzazione di interfacce Swing, andando a testare lo stato dei vari "model" dei componenti. Tornai a casa entusiasta e provai a mettere in pratica la lezione: fu un disastro! Questo per due motivi. In primo luogo non sono un programmatore valido come Bossola (e allora ero ancora molto meno esperto). Secondariamente lo sforzo per cercare di domare le idiosincrasie di Swing non portava alcun vantaggio. I problemi della GUI sono al 90% del tipo: "Se visualizzo la mia maschera a 800x600 anzich a 1024x768 i bottoni scompaiono", oppure "Se passo a 1280x1024 il carattere cos piccolo che non si legge una fava". Certo, il debugging di questi aspetti si pu fare anche con il TDD, ma penso che il debugging umano sia insostituibile, pi efficace e molto meno costoso.

Secondo esempio. All'XP UG di Milano tentammo di sviluppare l'UG-Aggregator, una mini applicazione web per inserire e visualizzare gli eventi dei vari XP-UG. Questa applicazione non aveva alcun tipo di logica significativa, ma noi, essendo agilisti DOC, dovevamo scrivere i test! Ci venne quindi l'idea di testare la struttura dell'HTML prodotto, per vedere che ci fossero determinati tag con attributi che dovevano identificarne il contenuto. Il risultato fu circa il seguente, correggimi se sbaglio: tempo per scrivere il codice 1, tempo per scrivere il test 2, tempo per debuggare il test (e non il codice) che non funzionava 4. (OK ho un po' esagerato, ma penso che la mia ricostruzione non sia troppo lontana dalla realt). Questo a mio avviso un esempio di programma senza logica per cui il TDD pu non essere efficace. Inoltre in questa situazione modificammo non solo la struttura interna dell'applicazione per renderla pi testabile, ma anche il suo comportamento. Questa ritengo sia una "puzza" del processo di test!

In questo senso mi ha confortato l'esempio di TDD presentato nell'ultima riunione dell'XP User Group di Bergamo da Alessandro melchiori e Emanuele DelBono. Partendo dai test stata abbozzata una banale applicazione Windows secondo il paradigma Model - View - Presenter. Ebbene, tutto il codice risultava coperto da test, ad eccezione della parte di view!
(Un unico neo nella presentazione dei due amici bresciani: tutto in C#!!!) ;-)