Chi ha seguito l'evolversi del progetto IMHO
probabilmente avrà avuto modo di notare come le feature del software siano
andate crescendo mano a mano che passavano i giorni, talvolta le ore. Il motivo
è presto detto, per la prima volta, sono riuscito ad applicare una metodologia
di sviluppo agile e cercando di focalizzare lo sviluppo delle varie
caratteristiche del mio progettino, su quelle che erano le cose essenziali
perchè si potesse dire che il software funzionasse.
Questo ha significato ad esempio, non solo pubblicare nella primissima
release un prodottino che si limitava a postare nel weblog di un singolo engine,
senza alcun supporto per le categorie e per una moltitudine di altre
funzionalità, ma anche approcciarsi nello sviluppo prerelease nello stesso modo.
Qualcuno avrebbe dovuto vedere cos'era IMHO prima di essere pubblicato, per
rendersi conto di cosa sto parlando. Basti pensare che il software è nato da una
serie di esperimenti condotti per vedere come funzionava .TEXT e il componente
DHTMLEdit. Mano a mano questi esperimenti sono diventati un software, raffinando
il codice e trasformandolo da un'ottica semplicemente strutturata ad una
propriamente object oriented.
Per ottenere questo, la massima parte del merito va al refactoring. Sono
rimasto molto stupito da quello che si può ottenere applicando bene in
refactoring al codice. Spesso, tempo fa ho ragionato su quella che chiamavo
l'entropia del codice, quando una serie di modifiche ripetute nel tempo allo
stesso programma causa una complessità tale da richiedere il
rifacimento totale del software. Come mi sbagliavo, questo non è il
risultato della modifica del codice, ma solo della sua incauta modifica,
solitamente per false questioni di economicità.
Occorre tenere presente che spesso, quello che si può capire, leggendo e
soprattuto scrivendo qualche decina di righe di codice, è infinitamente
superiore a quello che una seppur approfondita analisi e progettazione potranno
mai raggiungere. E questo apre le porte al refactoring. Non voglio ora
presentarmi come un estremista del refactoring, ma ritengo che utilizzandolo
bene, si possa tranquillamente scrivere una ottima applicazione partendo quasi
senza aver definito alcun design, per il semplice fatto che mentre si scrive il
codice questo design emergerà automaticamente (sempre che lo si voglia fare
naturalmente). L'importante è avere ben chiaro in testa, quali sono gli
obbiettivi che si devono raggiungere e soprattutto averli organizzati bene in
ordine di apparizione. Un esempio che vale per tutti in IMHO è ad esempio
la differenza che esiste tra la prima release e l'attuale implementazione dei
pluggable engines. Inizialmente gli engine non esistevano proprio. Vi era
semplicemente una serie di metodi, inseriti nello strato di logica che
incapsulavano le chiamate al webservice di .TEXT.
Scrivendo questo codice però mi sono reso conto che tali metodi potevano
tranquillamente incapsulare qualsiasi engine di weblogging e perciò ho deciso di
estrapolarli dallo strato di logica e di includerli in una classe che in
quel momento rappresentava esclusivamente l'engine di .TEXT. Il passo successivo
è stato quasi automatico. Data l'esigenza di interfacciarsi con un numero
imprecisato di engines, ecco nascere una EngineFactory, e la classe astratta
EngineAdapter. Ecco quindi implementati assieme un pattern AbstractFactory e un
Adapter a collaborare per rendere IMHO poliglotta.
Far diventare plugin un adapter ha comportato semplicemente la modifica della
factory. Ancora una volta pochi colpi di refactoring e il gioco è fatto. Però a
questo punto, è nata l'esigenza di rendere più adeguata a questo compito
l'interfaccia dell'adapter. fino a questo momento esso aveva dei metodi che
rispecchiavano i parametri richiesti dalle chiamate a .TEXT, ma altri engine
necessitavano di altri parametri. Anche questa volta il refactoring è stato la
chiave. Una riorganizzazione della classe Post e i parametri dei metodi
sono stati raggruppati tutti in una istanza di Post.
Ho già avuto modo di dissertare sulla propedeuticità
dei commenti, nel provocare sessioni di refactoring dagli eccellenti
risultati. Questo dimostra se ce ne fosse bisogno, non solo la positività del
commentare, ma anche che è la presa di coscienza del codice che causa la sua
revisione e riorganizzazione e quindi anche la sua qualità. Commentare è un'attività
che richiede di ripensare ai motivi per cui si
è scritto del codice, al perchè si sono adottate determinate soluzioni e quindi spinge
a chiedersi se esse siano quelle giuste, se non si poteva fare meglio e
di riflesso porta a realizzare questi pensieri.
Ora trovo queste metodologie indispensabili, non fosse altro perchè sono
incredibilmente foriere di buoni risultati e stimolano la creatività, dato che
suggeriscono la direzione verso la quale focalizzarla senza disperdere le
energie nel creare cose che non saranno mai utilizzate.
powered by IMHO