Correva il 2016 quando il mondo dello sviluppo venne scosso dal "caso left-pad", un incidente che mise in evidenza la vulnerabilità delle dipendenze nelle librerie software.
"Left-pad" era una micro-libreria pubblicata su Node Package Manager (npm), il gestore di pacchetti predefinito per Node.js. Svolgeva una funzione molto semplice: aggiungeva caratteri di padding a sinistra di una stringa, per assicurarsi che raggiungesse una lunghezza specificata.
Sebbene fosse una funzione banale e molto piccola (solo 11 righe di codice), era stata utilizzata come dipendenza da molte altre librerie JavaScript più grandi e più utilizzate.
Il problema si è verificato quando l'autore di "left-pad", Azer Koçulu, ha deciso di ritirare il pacchetto da npm dopo una disputa legale con un'altra azienda su un nome di pacchetto diverso che aveva registrato.
Poiché molte librerie dipendevano da "left-pad", la rimozione improvvisa del pacchetto ha causato il fallimento di migliaia di build e progetti in tutto il mondo, bloccando lo sviluppo di molte applicazioni.
Questo evento ha portato a una riflessione più ampia sulla gestione delle dipendenze nel mondo dello sviluppo software, mettendo in luce i rischi associati all'affidarsi a micro-librerie mantenute da singoli sviluppatori, spesso senza la dovuta attenzione o supervisione.
Ed è a questo episodio che si riallaccia Ben Visness nel suo "Micro-libraries need to die already" per spiegare, qualora ce ne fosse ancora bisogno, la rischiosità di delegare funzionalità banali a librerie di terze parti.
Questo atteggiamento è immediatamente comodo ma nel lungo periodo può avere conseguenze inaspettate e costose. Eppure ancora oggi c'è chi sostiene l'utilizzo di micro-librerie, argomentando che pacchetti più piccoli e numerosi migliorino il processo di sviluppo.
Tuttavia, questa visione può essere fuorviante e, in molti casi, controproducente per il business.
I Pro delle librerie di terze parti
È innegabile che l'uso di librerie di terze parti possa offrire alcuni benefici. Il primo, e più evidente, è il risparmio di tempo: le librerie pronte all'uso possono ridurre significativamente il tempo necessario per lo sviluppo, specialmente quando affrontano problemi complessi.
Il secondo è la robustezza del codice: librerie ben sviluppate possono gestire in modo più efficace casi limite e insidie che potrebbero sfuggire a un team di sviluppo interno.
Non vanno poi trascurati i continui aggiornamenti: le librerie di terze parti vengono spesso mantenute e aggiornate dagli sviluppatori originali, offrendo nuove funzionalità, correzioni di bug e miglioramenti della sicurezza.
Questi vantaggi, tuttavia, vanno bilanciati con una serie di potenziali svantaggi che possono avere un impatto negativo significativo sulla tua attività.
I contro delle dipendenze da terze parti
La prima cosa da osservare è che, salvo fortuite coincidenza, le librerie generiche non si adattano mai perfettamente alle specifiche esigenze del proprio progetto. Ciò può portare a un aumento del lavoro necessario per adattare il proprio codice alla libreria, annullando il risparmio di tempo iniziale.
La qualità del codice poi è incerta: non tutte le librerie di terze parti sono di alta qualità. Spesso, la popolarità di una libreria non corrisponde alla sua affidabilità o efficienza, e questo può portare a problemi di performance o, peggio ancora, a bug difficili da risolvere.
Ovviamente, bisogna considerare che il codice di terze parti introduce inevitabilmente rischi nella propria infrastruttura. Ogni libreria è un potenziale vettore per attacchi alla supply chain, e mantenere sotto controllo le dipendenze può diventare una sfida significativa, specialmente se si considera l'elevato numero di dipendenze transitive che possono essere incluse involontariamente.
Le librerie poi aumentano l’impronta digitale, includendo spesso una quantità di codice e metadati che non sono necessari per il proprio progetto, aumentando la dimensione complessiva del pacchetto. Ciò non solo rallenta i tempi di installazione e build, ma può anche degradare l'esperienza utente finale.
Da ultimo, specularmente a quanto scritto poco sopra, bisogna considerare le problematiche introdotte dagli aggiornamenti: sebbene essi possano portare miglioramenti, possono introdurre apportare non compatibili che richiedono riscritture e testing estensivi. Il che comporta costi aggiuntivi e tempi di sviluppo imprevedibili.
Il caso della micro-libreria "is-number"
Ben Visness argomenta poi la propria tesi prendendo come esempio la micro-libreria "is-number", che verifica se un valore è un numero finito.
Nonostante la sua semplicità, questo pacchetto ha subito numerosi aggiornamenti non compatibili nel tempo, dimostrando quanto possa essere rischioso affidarsi a librerie così specializzate.
Con un impatto minimo in termini di risparmio di tempo e robustezza del codice, l'uso di questa libreria potrebbe facilmente essere evitato scrivendo il codice necessario internamente.
La soluzione suggerita è dunque quella di ridurre le dipendenze e focalizzarsi sul codice interno. In molti casi, è più vantaggioso copiare e incollare semplici porzioni di codice nel proprio progetto piuttosto che installare e gestire una libreria esterna.
Questa pratica, spesso evitata per paura di duplicazione o errori, può invece garantire maggiore controllo, sicurezza e adattamento specifico alle esigenze del progetto.
Nel valutare se utilizzare una libreria di terze parti, è dunque essenziale considerare attentamente i costi e i benefici.
Sebbene le librerie possano offrire vantaggi in termini di tempo e risorse, i rischi associati (dall'adattabilità e qualità del codice ai rischi di sicurezza e agli aggiornamenti problematici), possono facilmente superare questi benefici.
Per un business, la chiave è trovare un equilibrio in grado di massimizzare l'efficienza senza compromettere la sicurezza e la qualità del prodotto finale.