Ho impostato la scaletta di quello che probabilmente sarà il mio intervento di apertura per la session:

• “Omogeneità di valori e imporre l’Agilità”

Chi segue la lista xp-it avrà notato la mia ignoranza in economia… :-O

Tuttavia sono convinto che per massimizzare l’efficacia del nostro lavoro, anche gli sviluppatori dovrebbere possedere almeno le nozioni di base, utili a creare una collaborazione molto stretta tra business-men e technical-men, nonché per farsi guidare dall’economic driver scelto misurandosi anche in tal senso. Del resto il manifesto Agile recita:

“Business people and developers must work together daily throughout the project”

Per questi motivi, mi aggrego a PierG che cita questo post, per colmare le mie lacune. Nei link che vi ho dato trovate i riferimenti alla wikipedia inglese, che sicuramente tratta in modo più completo l’argomento. Ad ogni modo volevo segnalare anche i seguenti link alla wikipedia italiana:

• Fatturato
• Ricavo
• Profitto
• ROI
• Utile

Credo che tutti abbiamo avuto questa esperienza: scrivere applicazioni che dopo x giorni si sono rivelate non più mantenibili, per le quali si impiegava meno tempo a riscriverle che a modificarle. Complice la tecnologia utilizzata, l’effort per riscrivere parti dell’applicazione  lasciava comunque il committente non contento dei nostri tempi di risposta e quindi del costo del software. In sostanza la bassa qualità del software prodotto si traduceva in alti costi di manutenzione.

La frustrazione provata in queste occasioni ci ha portato a chiedere: dove cercare la soluzione?

Sostanzialmente vi sono due strade opposte:

• addossare la colpa alla tecnologia utilizzata, e quindi cambiarla alla luce di questa affermazione
• cercare di migliorarci per costruire skill e capacità che ci permettano di non cadere nella trappola dell’applicazione zombie

Read the rest of this entry »

Gli ultimi due post (peccatore, e la rivincita), sono stati da me dedicati a parlarvi di un bug che mi ha tenuto occupato per più giorni. Come spesso accade il bug è tanto più infido e difficile da trovare, quanto banale nella sua soluzione.
In questo caso si trattava (appunto banalmente) di un doppio submit fatto da una form con un pulsunte di submit mal scritto. Il button era così scritto: Read the rest of this entry »

Per testare una possibile soluzione a questo bug avevo la necessità di testare l’utilizzo della CPU di un’applicazione Java che in alcune situazioni può creare N thread in parallelo.

L’occasione è stata ghiotta per sperimentare un’estensione di JUnit che permette di testare ambienti multithread. JUnit infatti non offre supporto nativo per questo task, ed anzi il testing in multithread è stato visto dai TDD-scettici come un forte limite all’adozione reale del TDD, ma con GroboUtils o TestNG è ormai banale riuscire a lanciare N thread e a testare che valgano delle proprietà alla morte di tutti i thread in questione, piuttosto che testare che i thread muoiano entro un periodo di tempo, eccetera.
Read the rest of this entry »

Oggi vado a casa da peccatore: ho risolto un bug su un’applicazione non scritta da me, e il codice corretto sarebbe da rifattorizzare, ma ho paura. Ho paura perché quel codice non ha nessun test automatico, e perché non mi è chiaro fino in fondo quali requisiti funzionali quel codice implementa.

Inutile dire inoltre che non sarebbe così facile e rapido scrivere dei test “post coding”, magari con l’aiuto dell’esperto di dominio, a causa del design del codice stesso. Persistenza (su più db), service layer e business layer sono una cosa sola, e l’ereditarietà la fa da padrone.

Ma poche scuse: oggi vado a casa da peccatore perché non sono ancora abbastanza bravo da scrivere i test nelle condizioni più ostili: IDE ostile, design ostile, tempi stretti e un ambiente di test di fatto non utilizzabile.

La domanda che mi pongo è: “Quanto voglio diventare bravo?“

L’esperto di Java per eccellenza (Bruce Eckel) scrive in un post non proprio recente (i grassetti sono miei):

In fact, what we need is

Strong testing, not strong typing.

So this, I assert, is an aspect of why Python works. C++ tests happen at compile time (with a few minor special cases). Some Java tests happen at compile time (syntax checking), and some happen at run time (array-bounds checking, for example). Most Python tests happen at runtime rather than at compile time, but they do happen, and that’s the important thing (not when). And because I can get a Python program up and running in far less time than it takes you to write the equivalent C++/Java/C# program, I can start running the real tests sooner: unit tests, tests of my hypothesis, tests of alternate approaches, etc. And if a Python program has adequate unit tests, it can be as robust as a C++, Java or C# program with adequate unit tests (although the tests in Python will be faster to write).

Quindi: attenzione a passare ai linguaggi dinamicamente tipati: non avrete nessuna scusa per non fare TDD!

Ieri a Milano, nell’ultimo incontro dell’XP-UG Milano, ho seguito con interesse il seminario di Matteo su Ruby on Rails, nel tentativo di vederlo all’opera con una demo-live e di mitigare alcuni dei dubbi che avevo sul framework. Read the rest of this entry »

Capitano giornate nelle quali manca la motivazione, ci si sente svogliati, si comincia un pomodoro ma non si riesce a mantenere viva la concentrazione per terminarlo gestendo le interruzioni.

Capitano giornate nelle quali “il prossimo pomodoro andrà meglio” non è sufficiente.

Capitano giornate nelle quali manca talmente la motivazione, che anche scorrendo il magazzino delle attività alla ricerca di un’attività stimolante non si è grado di scorgerla. Read the rest of this entry »

Come già annunciato nell’ultimo post di Enri Blog questo è il nuovo sito che ospiterà le mie riflessioni e quelle di Simone con voi.

Il progetto e gli intenti sono del tutto simili a quanto avete sopportato su wordpress.com, solo il nome ora dovrebbe rivelarli meglio: confrontarmi con voi sul tema del miglioramento continuo in ogni ambito, con particolare enfasi su ciò che ritengo più di ogni altra cosa importante nel nostro lavoro: scrivere codice di qualità che risolve problemi concreti in modo semplice, con umiltà e spirito collaborativo.

Chi voglia collaborare con me, può registrarsi al blog da questo indirizzo e spedirmi un email: provvederò a dargli i permessi per postare su questo spazio le sue riflessioni.

Aggiornate i vostri link ed i vostri FEED: post e commenti.

Il colore del tema non poteva che essere il rosso: failure is progress!.

Technorati Profile