[XP] Principi di sviluppo di Tommaso Torti

In questi anni di lavoro come extreme programmer ho avuto modo di provare su pelle molti dei principi, valori e pratiche che si leggono su libri.

Le ho sperimentate principalmente in due team, l'ex Xplayers team di Quinary e l'attuale team Orione di Sourcesense.
Altre volte le ho affinate nei gruppi in cui mi sono trovato a fare mentoring, negli scambi epistolari con la mailing list di xp-it e nel xp-user group di Milano.

Ho così coniato dei miei slogan; condivido con voi i principi vertuosi così come li ho interiorizzati.

1) Assolutamente al primo punto e con ampia distanza da qualsiasi altro:
UNA SOLA PARENTESI APERTA

Vuol dire: fai una e una sola cosa alla volta.
Si concretizza nelle pratiche:

• frequenti commit, che vuol dire darsi la possibilità di sbagliare e fare revert senza pietà. Aimè sono pochissime le persone che fanno revert e che ignorano la potenza del fare un passo indietro per farne due aventi.

• distinguere bene quando si scrive codice da quando si rifattorizza.

• l'uso della TODO list, anch'esso rarissimo. Quando mi capita di finire la mia funzionalità prima di prenderne una nuova chiedo ai miei compagni di team se hanno tasks che posso completare delle loro user stories. Li vedo sempre impacciati nel darmi una risposta chiara e concisa.

Se si mantiene una sola parentesi aperta, tutto ciò che è extra va a finire su un pezzo di carta. Quali vantaggi? Ci si dà la possibilità di dare priorità, di alternare le attività secondo le energie del momento etc.

2) DARE ALMENO 3 SOLUZIONI AD OGNI PROBLEMA
E' necessario ampliare lo spazio soluzione di ogni problema. Ciò che accade è che spesso si scelgono le soluzioni meno pulite perchè non si conoscono alternative. Se non si riescono a trovare alternative bisogna sforzarsi di farlo.
Come? Chiedendo in mailing list, scoprendo come altri hanno risolto lo stesso problema, come si risolve in letteratura, confrontandosi con colleghi piu esperti etc.
L'applicazione di questa pratica è una grande accelerazione nella carriera che porta uno junior a diventare senior.


3) IL CODICE DEVE ESSERE SIMMETRICO
Cosa non va nel seguente codice?

if (aa instanceof Father) ....
if (aa instanceof Mother) ....
if aa == null ....
if (aa instanceof Object) ....
E' una chiara violazione del paradigma object oriented ma sopratutto stona da un punto di vista prettamente estetico. La precondizione di ogni refactoring è la sensibilità, e la simmetria è uno dei modi per aumentarla.
Ho in mente l'immagine di tempio greco, dove le colonne sono di ugual numero a destra e a sinistra dell'entrata ed hanno stessa altezza. Il codice deve rispecchiare tale simmetria per essere elegante.


4) IL PROBLEMA DEL TDD E' IL TERZO PASSO
Non c'è niente da fare, il refactoring ad OGNI barra verde è difficilissimo dal punto di vista della disciplina. Si tende a scrivere altri test case, a rifattorizzare 'alla fine'. Quel che accade è che i refactoring sono sempre più grossi del necessario e si procede lentamente; inoltre non è raro lasciare debito tecnico.
Quando lo si vede? Quando ad esempio per scrivere un nuovo test case duplico uno esistente, e magari mi sembra anche giusto! Wrong!
Non c'è soluzione precisa a questo errore, ci vuole solo grande disciplina.

5) COMBATTI LE BATTAGLIE GIUSTE (ABBANDONA TEMATICHE ESTETICHE )

In un team ci sono sempre punti di vista differenti, ma bisogna scegliere la battaglia da combattere.
Sopratutto vale la pena concentrarsi sugli argomenti davvero sostanziali. Un tipico esempio sono le battaglie per l'uso dei generics o per l'introduzione di getter e setter.
Un altro esempio personale è la preferenza verso le stime in termini temporali rispetto alle stime con punti complessità. Ho le mie motivazioni, teoriche e pratiche, che mi portano a favorire una soluzione rispetto all'altra, ma reputo che non vale la pena combattere. A volte le persone hanno bisogno di sbagliare. Eppure il vero valore delle stime è rendersi conto del lavoro che c'è da fare, dei rischi associati, degli eventuali split etc., in fondo non è _così_ importante combattere questa battaglia (anche se so di essere nel giusto :) )

Questo vuol dire scendere a compromessi, che è una qualità e non un difetto di un programmatore che lavora in team.


6) NO SILVER BULLET

Mai adottare un atteggiamento del tipo: "non si fa così", o "si deve fare così".
Tale fanatismo è facilmente presente negli agilisti, ed è il primo pensiero che mi viene quando nascono dei movimenti di pensiero tipo quelli per l'adozione della tecnica del pomodoro o della campagna anti-if.
Non è così raro incontrare punti di vista assoluti, che ammazzano la libertà, il divertimento e sopratutto l'efficacia dello sviluppo in nome di principi ragionevoli.
Esempi: "non ci devono essere new nel codice" , "non ci devono essere check sul null nel codice", "no warning nel progetto", "solo test con mock" , "sempre loggare questo e quest'altro", etc etc


7) TUTTO CHIUSO A FINE GIORNATA
Per chiudere il cerchio, una variazione del punto 1. Una giornata non è che una singola parentesi all'interno dell'iterazione. Quindi: nessuna modifica non committata sulla macchina di sviluppo, il sistema di integrazione continua è verde con l'ultima versione rilasciata, il journal è stato scritto, il tracking è stato completato, le carte sono sulla lavagna etc etc.

Ovviamente ci sono le dovute eccezioni e la capacità di non cadere nel fanatismo (punto 6) sono tante. L'importante è tendere all'eccellenza ed evitare di mettere sul tavolo troppi compromessi.