Sunday 27 February 2011

Coding under pressure with TDD/BDD – Fantastica giornata

Ieri ho partecipato ad un originale evento open-space su TDD/BDD a Cambridge organizzato da Alan Hemmings e guidato da Alan Dean, il Chairman di ALT.NET UK nonche’ l’inventore degli Open Spaces Coding Days.

E’ stato davvero un fantastico evento e voglio condividere con voi la giornata.

Luogo
L’evento si e’ tenuto all’interno di una piccola azienda agile chiamate “The Agile Workshop”. Ringrazio Ronnie Barker e Stephen Oakman per l’accogliente ospitalita’ e la condivisione della loro profonda esperienza.

La mattina – Discussioni aperte
Prima di tutto a turno ci siamo presentati e abbiamo espresso le nostre aspettative per l’evento che si stava per svolgere. In questo modo Alan ha creato sulla lavagna un elenco puntato dei temi principali di discussione. Fatto questo abbiamo analizzato i vari punti e li abbiamo raggruppati in sezioni che alla fine erano praticamente due. Abbiamo quindi formato due gruppi di discussione indipendenti cercando di rispondere e condividere le proprie esperienze sui punti individuati. Fatto questo poi abbiamo unito tutti i gruppi e tratto alcune considerazioni finali. A turno ci e’ stato chiesto quale fossero le cose portate a casa da questa discussione.

Pranzo
La discussione ovviamente e’ continuata a pranzo in un pub inglese.

Il pomeriggio – Laboratorio
I temi di discussioni e una votazione preliminare hanno fatto emergere l’interesse di creare due laboratori paralleli:
  • Laboratorio base di TDD
  • Laboratorio avanzato di TDD/BDD
Sono stati nominati due persone per guidare ciascuno dei laboratori.
Io ho partecipato al laboratorio di base su TDD guidato da Alan Dean dove abbiamo svolto in pair programming un kata tratto dalla lista di eserci TDD per principianti: http://sites.google.com/site/tddproblems/

Il giudizio complessivo della giornata e’ veramente ottimo e mi ha permesso di conoscere molti appassionati programmatori inglesi allargando la mia rete di contatti professionali.

Sunday 6 February 2011

[Books] Coders at Work - Jamie Zawinski

Il libro Coders at Work contiene interessanti interviste a famosi programmatori.

In questo post voglio scrivere qualche commento all’intervista a Jamie Zawinski:

Cosa condivido:

  • Il modo migliore per immergersi in un pezzo di codice e’ prendere un task che si vuole realizzare e provare a farlo.
  • Se vuoi che il prodotto sia realmente cross-platform, devi rilasciarlo per tutte le piattaforme simultaneamente. Il risultato di un porting e’ un prodotto schifoso sulla seconda piattaforma.
  • La caratteristica che rende il codice piu’ facile da leggere sono i commenti. Scrivere le assunzioni e cosa fa un certo pezzo di codice.
  • Non essere spaventato dalla tua ignoranza. Se tu non capisci come qualcosa funziona, chiedi a qualcuno che lo sa. Non conoscere qualcosa non significa che sei stupido, semplicemente significa che tu non la conosci ancora.
  • Considera persone laureate che hanno utilizzato Java e mai C/C++ bizzarro e sbagliato.
  • Un aspetto chiave di un programmatore deve essere la curiosita’, voler sapere come le cose funzionano “under the hood”
  • Una importante capacita’ e’ essere capace di esplorare il codice scritto da qualcun altro e come utilizzarlo/modificarlo.
Cosa non condivido:
  • Gli Unit tests non sono critici. Se non ci sono unit test il cliente non si lamenta.
  • Il libro “Design Patterns” fa’ schifo. E’ giusto programmazione via taglia e incolla.
Insegnamenti e spunti per il futuro:
Ho meno di un anno di esperienza commerciale nello scrivere software e fino ad allora non avevo mai messo mano a software scritto da altre persone al di fuori di me. La prima grossa difficolta’ che ho provato dal primo giorno di lavoro e’ proprio quella di avere davanti una marea di codice gia’ scritto e doverlo capire e modificare. Credo sia abbastanza facile farsi prendere dal panico e imparare a farlo e’ veramente di una importanza cruciale nei nostri giorni dove e’ praticamente impossibile realizzare software di una certa rilevanza da soli chiusi in camera. Sembra proprio che non ci siano libri che trattino questo aspetto in una maniera sufficientemente chiara. D’altronde e’ un tema estremamente generico e l’esperienza e’ completamente diversa da software a software e da team a team. Una cosa pero’ ho capito dalla mia esperienza. Ho avuto modo di lavorare su codice legacy, senza test e senza una forte struttura e ho avuto modo di lavorare su codice veramente di ottima qualita’, ben commentato, ricco di test e con una struttura e dipendenze chiare. Inutile dirvi quanto l’immersione nel secondo progetto sia stata decisamente piu’ piacevole ed agile. Scrivere sofware di qualita’ ha molti vantaggi e questo e’ senz’altro uno di quelli.
Ho sempre avuto un approccio molto accademico alla programmazione: acquistare un libro, leggere gli esempi di codice, provarli e imparare creando qualche demo. Tuttavia questo approccio e’ particolarmente lento e forse per certi versi anche un po’ noioso. Ho sempre avuto un po’ di paura nel prendere e leggere codice scritto da altri, questo e’ stato il mio principale freno. Mi piace una introduzione sequenziale ad una tecnologia, con esempi di complessita’ crescenti che aiutino a comprenderla a fondo (appunto un approccio accademico). Tuttavia mi rendo conto che la fuori (anche in questa community) ci sono persone che imparano estremamente in fretta e forse uno dei motivi e’ proprio perche’ leggono (e scrivono) molto codice. Grazie a sofware open source abbiamo a disposizione una valanga di codice da cui trarre spunto e riflettere. Si tratta solo di iniziare a farlo sul serio…
Sito web del libro:
http://codersatwork.com/

[Books] Coders at Work - Brad Fitzpatrick

Il libro Coders at Work contiene interessanti interviste a famosi programmatori.

In questo post voglio scrivere qualche commento all’intervista a Brad Fitzpatrick.

Cosa condivido:
  • Io giusto assumo che qualcun altro non capira’ alcune delle invarianti che ho. Cosi’ praticamente mi assicuro di avere un opporunto test.
  • Tipizzazione statica e controlli a tempo di compilazione sono di grande importanza.
  • C++ ha una sintassi terribile e totalmente inconsistente e i messaggi di errore, almeno da GCC sono ridicoli. Puoi ottenre quaranta pagine di errori semplicemente perche’ hai dimenticato un punto e virgola.
  • Conosco persone molto intelligenti che conoscono solo Java. Io penso che e’ realmente importante conoscere l’intero stack anche se tu non operi all’interno dell’intero stack.
  • Un consiglio ai programmatori:
    • Sempre provare a fare qualcosa un po’ piu’ difficile, fuori dal quello che puoi pensare di realizzare.
    • Leggere codice. Non essere spaventato dal farlo. Dopo un po’ inizierai a vedere “pattern” nel codice scritto dagli altri.
  • E’ importantissimo avere un consistente stile di codifica all’interno del team/progetto che sia documentato e rispettato
  • Penso che la “pair programming” sia divertente. E’ ottima per molte cose e forza a non annoiarsi.
  • Non penso che il codice debba essere posseduto. Il codice e’ scritto dal team nella sua interezza e le revisioni di codice sono importantissime per mantenere alta la sua qualita’.
  • Un grande programmatore ad un colloquio si riconosce anche da cose che ha fatto nel tempo libero senza avere obblighi. Questo dimostra passione.
  • Non pensare di conoscere un algoritmo senza averlo mai scritto personalmente. Scrivere un algoritmo ti forza a capire tutti i casi limite e quindi lo imparari veramente
  • Le persone non vogliono scaricare programmi ora che esiste il web.
  • Essere personalmente coinvolti in community permette di crescere e incontrare persone di grande rispetto.
  • Non fidarti ciecamente del codice scritto da terzi o della documentazione. Prima scrivi un test che usa le funzioni che intendi usare per assicurarti che funzionino.
  • E’ importante pensare come uno scienziato. Avere pazienza e provare a capire la casa principale delle cose. Impara a scrivere le cose in modo incrementale cosi che in ogni fase tu possa verificarle.
  • Puo’ essere utile qualche volta scrivere qualcosa in un linguaggio nuovo e con cui non sei a tuo agio in modo da migliorare come programmatore.
  • Ricordati che in un team tutti dipendono da tutti. La collaborazione e’ fondamentale.
Insegnamenti e spunti per il futuro:
Condivito praticamente tutti gli aspetti principali sollevati da Brad.
Anche lui come Jamie Zawinsky riflette sull’importanza di imparare a leggere il codice scritto da altri, qualcosa sui devo assolutamente lavorare.

Sito web del libro:
http://codersatwork.com/