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?
4 replies on “Sulla riusabilità del codice”
source pattern o forse snippet pattern, o semplicemente coding pattern :-)
sottoscrivo tutto! :-) ma li terrei in parallelo ai desing (ed altri) pattern, così da non mescolare piani differenti
Non fa una piega! Spesso i progetti che si affrontano sono affini ma non uguali, quindi il riutilizzo del codice (per chi lo pensa come copia/incolla) non è immediato e richiede comunque adattamenti e/o modifiche. Quello che non cambia è effettivamente l’idea di fondo, l’approccio utilizzato, su cui basare lo sviluppo: dei pattern su cui si può fare affidamento sempre (con revisione periodica per adeguarli a nuove tecnologie disponibili).
Mi piace quando parli di riusabilità forzata del codice.
Mi sembra un modo come un altro per “mandare tutto in vacca”, sia perché come dici è stato concepito con uno scopo diverso, sia perché tante volte si tratta di una decisione presa dall’alto che può creare problemi (ci sono casi in cui lo sviluppatore “dimentica” di avere già risolto il problema, ma anche casi in cui ricorda benissimo di non averlo risolto).
Ma il punto più interessante è quello che riguarda il fatto che il vero patrimonio è la conoscenza di esserci già passati. Siamo sicuri che l’esperienza di esserci già passati si rifletta esattamente nel codice? Se sì, sono abbastanza sicuro che gli sviluppatori lo riutilizzeranno per lor scelta. In caso contrario la domanda diventa: come possiamo assicurare che il patrimonio di conoscenza condiviso non vada perduto? E le strategie sono ben diverse dal riuso coatto… condivisione, retrospettiva, pair programming, etc.
E’ un argomento che mi sta molto a cuore. Sto per dire una cosa banale e scontata, me ne rendo conto, ma mi capita di riscontrare che viene continuamente disattesa: il codice va (andrebbe) scritto o meglio ancora progettato dando per scontato che prima o poi verrà riutilizzato. Se ci si attenesse sempre a questo semplice principio e si applicassero di conseguenza tutte le best practice che ne derivano non si porrebbe, o perlomeno si ridurrebbe, il problema del riutilizzo del codice.
Un fattore importante è l’evolversi delle piattaforme e il cambiare dei linguaggi che usiamo. Ora che scrivo una REST API in Python con MongoDB come base dati è difficile che io riesca a riusare la mia bella libreria C#/.NET creata nel corso tanti anni di scrittura di applicazioni desktop. Potrei usarle in realtà, ma preferisco usare altre tecnologie, anche a costo di riscrivere l’ennesimo XML converter ;-)
La cosa si complica quando si lavora in team, naturalmente. Gestire e manutenere risorse condivise nel corso degli anni (e far si che tutti le usino volentieri e naturalmente, senza ricorrere a ‘shortcut’ fatti in proprio) è un impegno ciclopico, anche perché i team cambiano, nuove persone entrano e altre escono…