| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Get control of your email attachments. Connect all your Gmail accounts and in less than 2 minutes, Dokkio will automatically organize your file attachments. You can also connect Dokkio to Drive, Dropbox, and Slack. Sign up for free.

View
 

ReportMeet20080618

Page history last edited by Zoltar 12 years ago

Ci siamo trovati alle 19 presso la sede di Sourcesense.

 

L'argomento della serata è: testare un intervento che Matteo ha intenzione di portare alla Essap. Si tratta di un workshop di TDD con un po' più di enfasi sull'object oriented.

 

Il testo dell'esercizio: 10080616-extreme-oop.pdf

 

Eravamo in 9, un numero considerevole. L'esito finale è stato che (a quanto ho capito) le coppie hanno sviluppato al massimo fino alla storia dell'"Hello World."

 

Abbiamo iniziato (dopo uno spuntino a base di pizza) con 2 pomodori di sviluppo. Dopo il secondo pomodoro abbiamo fatto una sessione di design: Matteo alla lavagna ha disegnato un diagramma di collaborazione degli oggetti. La mia (Matteo) impressione era che ci fosse troppo poco design nel lavoro dei partecipanti; troppo hacking e troppo poco design. E lo scopo dell'esercizio era proprio fare emergere il design...

 

Dopo la sessione di design abbiamo fatto un'ultimo pomodoro di sviluppo, poi siamo andati a casa. (Sulla via del ritorno abbiamo trovato Tommaso, appena tornato da Roma dal corso per ScrumMaster con Craig Larman! Io, Fabio e Massimiliano siamo andati con lui a bere una birretta.)

 

Alcune idee sparse su come migliorare la sessione, che sono emerse durante la discussione finale:

  • Usare come esercizio un dominio più semplice; interpretare un semplice linguaggio è facile per chi si sia mai interessato di linguaggi e interpreti, difficile per chi non.
  • Spiegare prima di programmare come si fa una sessione di design.
  • Chiedere ai partecipanti di fare una sessione di design in comune prima di cominciare a codificare.
  • Fornire delle storie di granularità molto più grande; quelle che ho messo nell'esercizio erano troppo piccole: il lavoro di scegliere il primo test era già stato fatto da chi ha scritto le storie. Inoltre vedere una storia che faccia di più di un semplice "input stringa vuota, output stringa vuota" ti dà lo stimolo e l'interesse per impegnarti a completare l'esercizio
  • Spiegare come funzionano gli stub prima dell'esercizio; fare una dimostrazione.
  • Spezzare la sessione in due: prima parte, esercizi sugli stub. Seconda parte, applicarli per fare design e tdd insieme
  • Eliminare alcune delle regole restrittive di cui sopra; Fabio ha osservato che il 90% del beneficio si ottiene rispettando solo queste:
    • no getters
    • livello di indentazione limitato a 1
    • wrappare tutti gli oggetti primitivi
    • (eventualmente) non mettere due "." sulla stessa riga
  • I mock sono troppo avanzati per un esercizio di una sola mezza giornata... per imparare l'utilità dei mock conviene prima avere imparato ad arrangiarsi con stub fatti a mano.
  • Preparare un progetto Eclipse con un minimo di funzionalità già funzionante
  • Aggiungere storie che richiedono di simulare l'input dell'utente. Questo forzerà l'introduzione di mock alla periferia del sistema.

Comments (0)

You don't have permission to comment on this page.