Nessuno se la prenda se adesso dirò che l'intervento che
mi ha regalato le maggiori soddisfazioni al Workshop è quello che ha tenuto
Marco Abis. Rispetto le metodologie di sviluppo agile mi sono da sempre sentito
vicino e convinto, ma davvero mai avevo sentito narrare con tanto trasporto di
questo argomento.
Eccomi quindi ora, ancora una volta, a ricordare alcuni passi di
quell'intervento, che mi sono stati ricordati dalle foto nel blog di Luca
Minudel. In particolare mi riferisco al momento in cui Marco, davanti ad un
grafico che indicava l'andamento dell'indice ciclomatico, puntanto il dito sul
culmine di una curva sosteneva che quello fosse il momento in cui inizia il
refactoring.
Togliete il cappello da "maialino" e mettete quello del refactoring, e la
curva si abbassa.
Molti di noi sanno che in realtà, quello che succede è che il cappello da
maialino raramente ce lo fanno togliere, e quindi alle fine l'andamento di un
progetto nel tempo è molto più simile ad una scalata dell'Everest che alla
passeggiata collinare che il grafico ci suggeriva. Nell'economia dei tempi e del
business "miope", quello che succede è che una volta arrivati al culmine della
curva, ove tutto funziona, male ma funziona, arriva il capo e ci informa che sì,
siamo stati bravi, abbiamo risolto il problema, ma siccome lui dovrà passare il
Natale alle Bahamas è opportuno che il progetto finisca lì e che si cominci ad
arrancare sulla dorsale "ciclomatica" di un altro progetto, cercando di arrivare
alla sospirata vetta "ciclomatica".
La mia non vuole essere una critica all'intervento di Marco, ma
piuttosto un prendere coscienza di tali problematiche, per darvi una risposta,
nella convinzione che mi muove che il ragionamento fila e anche bene. Il nostro
sforzo quindi deve essere quello di andare oltre la curva. Non importa quando,
come o perchè, ma dobbiamo avere la capacità di sentire il nostro codice, i
fasci di istruzioni che lo percorrono e che ne danno vita, gli intoppi che tali
istruizioni incontrano e spianarli, facendo sempre qualche passo oltre la
curva.
Non necessariamente è obbligatorio che il refactoring avvenga quando il
codice è terminato e funzionante. L'occasione si può incontrare più facilmente
invece quando si aggiungono nuove funzionalità. Una volta che si è giunti in
vetta non ha probabilmente alcun senso intervenire nel codice che funziona (con
buonapace delle ferie del nostro capo), ma lo ha certamente correre a testa
bassa sulla china del refactoring per preparare la rincorsa che ci consentirà di
raggiungere le vetta successiva.
Personalmente vedo questa attività analoga al reimpastare la creta, per
renderla più malleabile, in vista della azione scultorea che essa dovrà subire
fino a raggiungere la forma desiderata. Lo stesso avviene con il refactoring. Si
prende il codice, lo si osserva bene e si comincia a menare fendenti. Una classe
nasce e un'altra muore. un parametro cambia tipo, una metodo cambia nome,
una variabile fa altrettanto. Il tutto in una azione coordinata di
accerchiamento al problema che lo stritola. E alla fine si è pronti. Si
mettono assieme le cose e la vetta è raggiunta.
Davvero credetemi. non mi capita spesso di parlare di qualcosa con tale
veemenza, ma lo faccio proprio perchè ritengo che se è vero, come penso che sia,
che la programmazione è solo un'altra forma di arte, la più nuova e sconosciuta,
allora il refactoring è la giusta strada.
powered by IMHO