Un blog, un altro blog, un libro e un film.

Con spirito schizofrenico da una parte e prudenza giuridica dall’altra – non abbiamo ancora bene capito cosa potremo ben scrivere – Francesco e io vi presentiamo il blog dedicato al nostro libro Pro PHP Refactoring with Test Driven Design. Poi magari non vi potremo scrivere niente di rilevante; poi magari non vi scriveremo niente che non si possa scrivere sui nostri rispettivi blog; poi magari non ci verrà niente in mente di interessante da scrivere; però oh, noi intanto lo abbiamo tirato su, con buona pace degli spider di Google.

Siamo già a caccia di lettori replicanti, non umani. Alla faccia di Rick Deckard!

September 20 2009 | Recensioni | 2 Comments »

Agile UX, Facebook e il refactoring delle interfacce

In un recentissimo post di Alberto Mucignat, caro amico più volte ospite di questo blog, nonché esperto progettista di interfacce, si possono leggere sintetizzati i punti salienti per capire come lavorano gli interaction designer di Facebook.

Sebbene mi piacerebbe soffermarmi sul punto

3. I designer lavorano principalmente in codice (html/css e un pizzico di php)

tradendo così la mia estrazione da sviluppatore e confermando il codice come valido (!= perfetto) formalismo per questi scopi, preferisco invece farti notare questo:

4. Non si affezionano troppo al lavoro: il software cambia continuamente.

È più di un anno che scrivo e dico che l’unica via per rendere più agile il lavoro degli interaction designers è basata su due punti:

  1. Trovare strumenti che permettano il facile refactoring dei wireframe.
  2. Adottare una filosofia di progettazione più incline al rifacimento e meno al desiderio di essere – disperatamente – up front.

Il primo vincolo potrà anche essere squisitamente tecnico – ed è solo questione di tempo, ma il secondo non è che di natura umana.

E ti pare poco!

September 17 2009 | Dalle trincee | 6 Comments »

La prima volta

Avevo pronta una categoria recensioni da tempo qui per questo blog. Non l’ho più usata un po’ per questione di priorità di argomenti – il tempo per scrivere è già così poco :( – un po’ per doverosa umiltà: perché dovrei recensire libri altrui? Allora comincio dal mio. Anzi, dal nostro.

Scrivo nostro perché ne sono co-autore con Francesco Trucchia. Insieme a lui avrò il piacere di scrivere per Apress il libro intitolato Pro PHP Refactoring with Test-Driven Design la cui pubblicazione è prevista per il prossimo febbraio.

Ah già, perché dimenticavo: il libro non lo abbiamo ancora scritto! Quindi anche oggi non posso recensire alcunché. :)

September 12 2009 | Recensioni | 4 Comments »

Scrum non basta. E nemmeno XP.

In un saliente post del caro Alessandro Astarita leggo

Per avere successo con Scrum, XP o ogni altra metodologia agile, bisogna fare refactoring. Non è opzionale, è indispensabile.

tratto da un post di Ron Jeffries.

Il refactoring è una pratica essenziale. Essenziale, nel caso la sedimentazione linguistica non lo portasse alla luce immediatamente, significa relativo all’essenza, fondamentale, che è assolutamente necessario.

Assolutamente necessario.

Troppo spesso si parla di agile – buzzword che francamente sto cessando di impiegare – e si pensa di poter garantire evolutività incrementale solo con un po’ di iterazioni buttate in un calendario e delle user story scritte male. Bisogna essere produttivi per un mercato che cambia. Bisogna essere pronti a rispondere agli stimoli.

Il codice deve essere pronto a seguirci. Ovunque.

June 20 2009 | Base | 1 Comment »

Extreme programming e domain driven design

Ieri ho partecipato al primo giorno del phpDay 2008, in attesa di pubblicare con Francesco il nostro workshop oggi pomeriggio. Giornata divertente come ogni anno mi aspetto che sia, resa più frizzante dalla richiesta improvvisa di Fullo di aiutarlo a riempire un buco venuto improvvisamente a crearsi nell’agenda della giornata. Pensavo di fare un talk veloce sulle metafore fisiche con cui mi capita di descrivere (o di veder descritti) i processi agili, poi però Francesco mi ha dato l’idea migliore – parlare del Domain Driven Design – che ho poi deciso di integrare con riferimenti all’extreme programming.

Il domain driven design è una metodologia di modellazione del software che parte dal presupposto per cui gli sviluppatori devono nel tempo distillare una sempre maggiore porzione di conoscenza di dominio nella struttura del codice scritto, conoscenza che proviene dal contributo degli esperti di dominio, tipicamente il cliente.

Un obiettivo fondamentale di questo processo è quello di creare un ubiquitous language che sia condiviso tra team di sviluppatori ed esperti di dominio, che si rifletta fino in fondo alla scelta dei nomi delle classi, dei metodi, delle interfacce e delle strutture relazionali tra oggetti, in modo da

  • rendere più affidabile il design dell’applicazione
  • rendere più semplice la partecipazione del cliente alla progettazione stessa

Il che già di per sé sembra fortemente propedeutico per la pratica extreme programming denominata customer on site che richiede al cliente di essere presente direttamente – o per delega – presente presso il team di sviluppo del progetto di cui è committente.

Ma se poi andiamo a fondo nell’apprendimento del domain driven design scopriamo anche il concetto di continous learning e di new insight che riflettono il fatto che gli sviluppatori, man mano che vivono all’interno di un progetto, ne assimilano i concetti di dominio fondamentali e sono perciò portati a modificare il codice per riflettere questo incremento di conoscenza. Il libro di Eric Evans fornisce molti utilissimi consigli per ottenere codice che sia facile da manutenere e far crescere, ma per noi agilisti è chiaro che vengono alla mente i concetto di design emergente e, ancor di più, di refactoring.

Extreme programming quindi ci fornisce delle pratiche che, se seguite con attenzione, ci permettono di modificare il codice senza timore, di tenerlo pertanto aderente alla realtà di dominio e quindi di perseguire il continous learning senza attriti ed ostacoli di sorta.

È chiaro quindi come il domain driven design possa essere propedeutico alle pratiche agili, ma anche come extreme programming possa esserlo per l’incremento di conoscenza del dominio che una modellazione domain driven presuppone.

May 24 2008 | Esperti | 1 Comment »