Fullo

Sulla riusabilità del codice

Passando molto più tempo a gestire la (follia della) gente che sul codice ho iniziato a rivedere alcuni concetti a me cari durante la mia precedente, e forse futura, vita da sviluppatore. Uno di questi è la riusabilità del codice.

Il primo tarlo sull’argomento si è presentato quando, durante l’Agile Day di Roma, mi è stato chiesto se in ideato reinventavamo la ruota ogni volta e per ogni progetto. In quell’occasione la mia risposta, data di getto e senza pensarci troppo, fu: “utilizzeresti del codice (anche tuo) scritto 4 anni fa?“. Il principio di base è che in 4 anni la tecnologia (sul web) evolve tantissimo, ed allo stesso modo evolvono le competenze dei team, riutilizzare quindi codice obsoleto e potenzialmente legacy non fa altro che limitare le potenzialità di uno sviluppatore (riducendo in alcuni casi la qualità globale del progetto).

Da li in avanti è stato un susseguirsi di discussioni sull’argomento in azienda su come interpretarlo al fine da ridurre gli sprechi e, contemporaneamente, non indurre una eccessiva complessità nei basecode che vengono gestiti.

La mia opinione è che, macroscopicamente, la riusabilità del codice, in un breve lasso di tempo (diciamo 1-2 anni), sia da incentivare.

Macroscopicamente significa però che vada incentivata per quella classe di strumenti che aiutano a scrivere codice (framework, CMF o set di librerie) facilitando, di conseguenza, la condivisione del knowhow e delle metodologie di lavoro all’interno del gruppo di lavoro. La scelta però di voler riutilizzare a tutti i costi un metodo, una classe, un particolare modello o un tool ben preciso è da sconsigliare perchè implica il voler forzare uno strumento a fare qualcosa per cui non è stato, inizialmente, concepito.

L’esempio più banale è quello di voler usare per ogni cliente un unico CMS (quindi uno strumento già specializzato in qualcosa). In questo caso il lavoro di personalizzazione di un modulo di pubblicazione di una pagina può risultare molto più costoso che limitarsi a fare uno scaffolding dei modelli da gestire che con semplici pagine hanno ben poco da spartire. Il codice riutilizzato forzatamente crea spreco e complessità invece che dare un vantaggio effettivo.

Quindi, penso che, il vero concetto che debba passare sia della riusabilità della conoscenza.

Così come i design pattern della GoF aiutano ad affrontare schematicamente problemi ben noti, allo stesso modo, acquisita una certa compentenza su una particolare classe di problemi è importante utilizzare quest’ultima per definire nuovi application pattern che possano essere utilizzati a loro volta per risolvere problemi attigui.

Un esperimento del genere fu fatto nel 2009 da Yahoo! che nel proprio Developer Network cercò di raccogliere pattern per il design di applicazioni utili alla definizione di funzionalità per rappresentare/definire concetti di reputazione, engagement o anche semplicemente paginazione dei dati (altro esempio molto interessante di archivio di design pattern è quello di Welie).

Il semplice design pattern però è troppo limitato per uno sviluppatore e dovrebbe racchiudere anche un po’ di informazioni utili all’implementazione di codice, una buona soluzione potrebbe quindi essere quella di sfruttare i pattern esistenti definendone però anche esempi di codice. Prendendo il design pattern dello “store locator” l’informazione essenziale per lo sviluppatore, più che la forma che il widget dovrà assumere, è sapere che le funzionalità di calcolo della vicinanza tra due punti sfruttano le librerie geospaziali presenti in molti database (MySQL, Postgres o MongoDB) o che l’intorno di un dato punto è calcolato usando funzioni trigonometriche. Con queste poche dritte (magari affiancate da link a risorse più esaustive o a codice pre-esistente fatto in casa) si riescono a ridurre ore di ricerce su internet e stress per esempi non utili o inapplicabili.

Definire un application pattern come quello per lo “store locator” comune a tutto il team di sviluppo, faciliterà l’identificazione del problema, della risoluzione e delle possibili implementazioni. Riducendo, non tanto il tempo di scrittura del codice, quanto quello di ricerca di una soluzione ottimale ed il numero di implementazioni radicalmente diverse.

Che ne dite?