Uno dei principi più importanti di XP, nonché uno dei valori fondanti, è: scegli la via più semplice.

Ad esempio, se ci si trova a dover scegliere tra due soluzioni, una che prevede un’infrastruttura più ampia, utile anche in futuro, ed una invece con un’infrastruttura ad uso esclusivo della business story attuale, XP guida nella scelta con l’euristica:

“scegli la soluzione più semplice, che non fa assunzioni sulle necessità future e che presuppone lo sviluppo solo dell’infrastruttura necessaria adesso, così da minimizzare il time-to-market e da non precludere alcuna strada futura”.

E’ l’essenza dello sviluppo iterativo.

La domanda ora è: scegliere in base a questa euristica, ottimizza il ritorno di investimento finale?

Nel corso di questo post per mezzo di un’analisi finanziaria comprenderemo in quali situazioni l’euristica XP è vincente rispetto ad una scelta con architettura up-front.

Read the rest of this entry »

Stavo leggendo gli ultimi post di PierG, dove oltre che ringraziareil leggendario Shumi, PierGiorgio cita il sito complexLab. Il sito contiene articoli molto interessanti e stimolanti sul tema “complessità e caos”. Sfogliando qua e là ho trovato questa illuminante recensione di un testo subito inserito nella mia WishList, di cui riporto qui qualche paragrafo e un mio breve commento:

La realtà è complessa o semplice? Dipende: il testo mostra con chiarezza come lo stesso fenomeno possa, senza mutare la sua struttura ma soltanto la dinamica di qualche suo parametro, passare da un’evoluzione deterministica prevedibile, a una ancora deterministica ma imprevedibile, per poi dissolversi nell’imprevedibile “sensibilità alle condizioni iniziali” del regime caotico. Lo stesso fenomeno!

A me fa pensare al design ad oggetti, dove Read the rest of this entry »

Si sente spesso dire che per utilizzare una metodologia come eXtreme Programming, e molte delle sue pratiche (su tutte il TDD), è necessaria una disciplina maggiore che con altre metodologie. Penso che ci sia un fondamento di verità in questa affermazione. Tuttavia il De Mauro definisce la disciplina come (il grassetto è mio):

L’insieme delle norme che regolano il comportamento di un individuo, un gruppo, un ente; rispetto, obbedienza di tali norme: imporre, violare, mantenere la d., è incapace di d., non sanno osservare la d. | estens., dominio dei propri istinti, desideri e sim. suggerito da principi etici o religiosi: si impone una ferrea d. .

Il termine disciplina richiama quindi fortemente un altro termine: rigidità. Come è quindi possibile che un paradigma che si pone come obiettivo dichiarato quello della flessibilità anche del metodo stesso, richieda a chi applica tale paradigma, disciplina e rigidità? Read the rest of this entry »

[iterazione 2 (27/9)]

Come già il buon FRANK ha notato, ultimamente il blog ha subito mutazioni di look giornaliere e da far girare la testa…

Tutto nasce dal post sul TDD e gli Unit Test che con il tema vecchio di wordpress, veniva visualizzato in modo poco chiaro. Da lì è cominciata la ricerca del tema, che per ostinazione somigliava più a quella del Santo Graal che ad un semplice cambio di look del sito. Sono infatti caduto nel problema del “Best is the enemy of Good“(TM), cambiando di giorno in giorno il tema senza mai esserne soddisfatto, al punto che il mio amico Simone è arrivato a dirmi “l’agile enri disagilizzato da un tema!”… Di seguito la mia breve autodifesa: Read the rest of this entry »

L’impedance mismatch tra il paradigma relazionale ed il paradigma ad oggetti è sicuramente uno dei temi più trattati e sentiti da parecchi anni. Per affrontare questo problema sono nati ormai più di dieci anni fa i primi database ad oggetti mai decollati, e sono nati framework che più o meno semplicemente, con maggiore o minore ambizione hanno cercato di gettare un ponte tra i due mondi. Le soluzioni di maggior seguito sono comunque tutte orientate ad implementazioni ad oggetti (da JDBC ad Hibernate, ad EJB) che rendano in qualche misura trasparente il mondo relazionale. E’ innegabile per chiunque che per quanto si cerchi di nasconderlo sotto il tappeto, il mondo relazionale salterà fuori tra gli oggetti quando meno ce lo aspettiamo, anche (o forse soprattutto) con i framework più ambiziosi.

D’altro canto ed ortogonalmente, un pattern nato nel mondo Smalltalk negli anni ottanta (l’MVC), è diventato la soluzione più utilizzata per la costruzione di applicazioni Web.

Quando si adottano le soluzioni più spinte nei due campi, ci si imbatte con maggiore forza nel problema del mismatch.

Read the rest of this entry »

Scrivere software di qualità è molto difficile, e tale difficoltà non solo è legata naturalmente alla complessità del dominio, ma anche a fattori più “umani” quali la comunicazione all’interno del team soprattutto quando composto da elementi di esperienza e formazioni eterogenee.

Una serie di tool ci viene in soccorso per monitorare continuamente la qualità del codice che stiamo scrivendo, e se unita alla pratica di Continuous Integration (ad esempio per mezzo di CruiseControl), permette di controllare continuamente e su base regolare se tutti i componenti del team stanno scrivendo software al di sotto degli standard di qualità prefissati. Prevenire problemi di comprensibilità e mantenibilità del codice, affrontandoli per tempo, è possibile rendendo visibili nel workspace le misure di queste caratteristiche, per mezzo di Big Visible Charts o di una Ambient Orb, cioè di una sfera che, comandata da un task di Ant, a seconda della qualità del codice si colora di verde o di rosso acceso.

I seguenti tool di controlli statici del codice permettono di tenere gli occhi ben aperti su questi aspetti:

• CPD (con PMD): identifica le duplicazioni del codice della nostra applicazione da parte degli sviluppatori più ansiosi o meno accorti; comunichiamo abbastanza?
• CheckStyle: verifica che le Code Convention vengano rispettate
• Metrics: riteniamo la programmazione ad oggetti una chimera o ci impegnamo a fondo per comprenderla?
• Clover: stiamo scrivendo abbastanza test?

Articoli:

• Automation for the People: continuous inspection