51 - Dipendenze Software

Ben ritrovati in questa nuova puntata. in questa puntata parliamo delle dipendenze software, librerie e moduli che semplificano lo sviluppo, ma che portano con se rischi e responsabilità.Analizziamo i vantaggi , i compromessi e i pericoli di affidarsi a codice esterno, con esempi reali come left-pad, event-stream e log4j. Una riflessione sull'equilibrio tra velocità, autonomia e consapevolezza nello scrivere software. Buon ascolto

Episode Transcript

(00:15):
Benvenuti ad un nuovo episodio. Prima di iniziare con
l'argomento di oggi vi invito a iscrivervi, attivare la
campanella e a lasciare una valutazione positiva, il vostro
supporto è fondamentale per far crescere questa comunità. e a,
migliorare ogni episodio se avete
d[e-mail] per la vostra attenzione

(00:37):
e buon ascolto. In questa puntata parleremo di
un tema che tutti i programmatori incontrano prima o
poi, le dipendenze software. Ma partiamo dall'inizio, che
cosa sono le dipendenze? Le dipendenze nel mondo del
software sono quei componenti esterni, librerie o moduli che
un programma utilizza per funzionare.
In pratica, invece di riscrivereda zero ogni funzione, gli

(01:00):
sviluppatori riutilizzano codicegià pronto, spesso realizzato da
altri sviluppatori. Questo approccio permette di
velocizzare il processo di creazione in modo da non
soffermarci troppo sulla realizzazione di un particolare
componente. Immaginiamo per un attimo di
voler gestire il processo di acquisizione dei permessi
durante l'esecuzione dell'applicazione di Android.
In questo caso possiamo muovercisu due binari, il primo di

(01:24):
utilizzare delle api standard che stesso il sistema operativo
ci mette a disposizione e quindigestire ogni aspetto, oppure il
secondo metodo. Utilizzare una libreria esterna
che ci nasconde parte del comportamento in questo secondo
caso, utilizzare una libreria esterna significa che qualcun
altro ha già scritto il codice necessario per gestire i
permessi, magari in modo più semplice o più elegante.

(01:48):
Noi dobbiamo solo includere quelle librerie e imparare a
usarle. Ed ecco il cuore del concetto di
pendenza, affidarci a qualcosa che non abbiamo scritto noi?
Ovviamente tale aspetto porta a considerazioni abbastanza forti,
perché affidarsi a una dipendenza non è mai una scelta
neutra. Significa incorporare nel nostro
progetto non solo il codice, ma anche le decisioni, gli stili e

(02:12):
persino le filosofie di chi quelcodice lo ha scritto.
In altre parole, quando importiamo una libreria stiamo
accettando di fidarci della qualità, della sicurezza e della
manutenzione futura di un progetto che non controlliamo
direttamente. È come comporre un puzzle e
decidere di usare un pezzo disegnato da qualcun altro.
Se quel pezzo è preciso e resistente, si incastra

(02:33):
perfettamente e ci permette di completare l'immagine, ma se è
difettoso o manca, rischia di compromettere l'armonia e la
solidità dell'intero quadro. Ed è proprio su questo aspetto
che vorrei soffermarmi, perché l'uso delle dipendenze non
riguarda soltanto la tecnica, maanche la mentalità con cui
affrontiamo la programmazione. Scrivere software non è

(02:53):
semplicemente mettere insieme righe di codice, è un esercizio
di responsabilità. Ogni dipendenza che scegliamo
rappresenta una decisione a lungo termine.
Può semplificarci la vita oggi, ma condizionarci domani.
Pensiamoci un attimo, se un progetto personale resta
bloccato perché una libreria nonviene più aggiornata, pazienza.
Ma se la stessa cosa accade in un software aziendale o

(03:15):
addirittura in un sistema critico, le conseguenze possono
essere enormi. Un piccolo componente trascurato
può diventare punto di fragilitàche mette a rischio l'intero
programma. Ecco perché è importante
sviluppare un approccio critico,non prendere mai una libreria
solo perché lo fanno tutti, valutare la sua affidabilità, la
sua comunità, il ritmo con cui vengono rilasciati gli

(03:37):
aggiornamenti, chiedersi sempre se il problema che risolve non
possa essere affrontato direttamente con un po' di
codice scritto da noi. In questo senso le dipendenze
diventano una palestra di consapevolezza.
Ci insegnano a distinguere tra ciò che è davvero utile e ciò
che invece ci rende soltanto pigri o troppo dipendenti dal
lavoro degli altri. E alla fine questa è una delle

(03:59):
lezioni più importanti per ogni programmatore, saper scegliere,
scegliere se affidarsi, scegliendo quando essere
autonomi, scegliere se costruireun equilibrio tra velocità e
solidità. Ormai siamo sempre più
consapevoli che esiste un pacchetto, una libreria, un
modulo che ci permetterà di ridurre il tempo di sviluppo.
Ed è proprio questa consapevolezza che ci porta una

(04:20):
specie di illusione, di sicurezza, l'idea che esista
sempre una soluzione pronta, giàconfezionata, da prendere e
incollare dentro il nostro progetto.
Ma la verità è che ogni volta che scegliamo questa strada
stiamo facendo un compromesso. Stiamo risparmiando tempo oggi,
ma stiamo anche accettando di legare il nostro lavoro a
qualcosa che non controlliamo. E questo non è necessariamente

(04:42):
un male, anzi, spesso è la scelta giusta, ma richiede
maturità e giudizio. Il rischio è trasformare la
programmazione in un semplice assemblaggio di pezzi altrui,
perdendo di vista la capacità dirisolvere i problemi con le
nostre forze. Ed è qui che nasce il vero
equilibrio, usare le dipendenze quando davvero accelerano e
arricchiscono il progetto, ma non lasciare che diventino un

(05:05):
stampelle costanti. Perché se ci pensiamo, il valore
di un buon programmatore non stasolo nel conoscere i pacchetti
giusti da installare, ma anche esoprattutto nel sapere quando
farne a meno. Ma dunque, arrivati a questa
parte della puntata, sorge spontanea una domanda, fino a
che punto è giusto affidarci alle dipendenze?
La verità è che non esiste una risposta assoluta, dipende dal

(05:28):
contesto, dall'obiettivo e anchedalla prospettiva con cui
guardiamo il nostro lavoro. Prendiamo due scenari opposti.
Da un lato abbiamo lo sviluppatore hobbista che vuole
creare un progetto personale in poco tempo.
In questo caso usare molte librerie può avere perfettamente
senso, riduce la complessità e permette di concentrarsi sul
risultato finale. Se la libreria un giorno smette

(05:49):
di funzionare non è un dramma, si tratterà al massimo di
abbandonare o rifare il progetto.
Dall'altro c'è lo sviluppatore professionista che lavora a un
software destinato a durare negli anni, magari in ambiente
aziendale o addirittura critico,come già abbiamo detto.
Qui il discorso cambia, ogni dipendenza diventa un vincolo,
un nodo che Lega il futuro progetto a decisioni prese da

(06:10):
qualcun'altro. In questo contesto la leggerezza
con cui spesso aggiungiamo librerie può trasformarsi in un
rischio enorme. E qui entra in gioco un concetto
che spesso viene sottovalutato, il debito tecnico.
Ogni dipendenza che introduciamoè come un prestito.
Ci dà subito qualcosa, tempo risparmiato, funzioni già
pronte, ma ci obbliga a ripagarein futuro, quando quella

(06:33):
dipendenza dovrà essere aggiornata, mantenuta,
sostituita. E come tutti i debiti, anche
questo accumula interessi. Più dipendenze abbiamo, più
diventa complicato gestire il progetto sul lungo periodo,
perché alla fine il software nonè fatto solo di righe di codice,
è fatto di scelte, e ogni sceltaracconta qualcosa di noi come
sviluppatori, del nostro modo diaffrontare i problemi e delle

(06:55):
responsabilità che siamo disposti a prenderci.
In questa parte finale della puntata vorrei soffermarmi su
alcuni esempi di cui l'utilizzo di un pacchetto esterno ha
provocato più danni che benefici.
Perché non parliamo solo di teoria.
La storia dell'informatica recente è piena di casi che ci
ricordano quanto sia delicato affidarsi ciecamente alle
dipendenze. Uno dei più noti è quello del

(07:17):
pacchetto left PAD, un piccolo modulo di javascript grande
appena 11 righe di codice che serviva a fare una cosa
banalissima, aggiungere degli spazi o dei caratteri davanti a
una stringa per allinearla. Eppure questo piccolo pacchetto
era diventato una dipendenza di centinaia e migliaia di progetti
nel mondo. Quando il suo autore decise di

(07:38):
rimuoverlo da NPM, l'intero ecosistema javascript andò nel
caos. Build che non funzionavano più,
progetti bloccati, aziende in difficoltà, tutto per 11 righe
di codice che chiunque avrebbe potuto scrivere da solo.
È stato un esempio lampante di come la troppa fiducia nelle
dipendenze possa generare una fragilità enorme.

(07:59):
Ma ancora un'altro caso riguardaLive in Stream dell'ex, sempre
nell'ecosistema javascript. Una libreria molto usata per
gestire flussi di dati, anch'essa inclusi in migliaia di
progetti. A un certo punto lo sviluppatore
originale, stanco di mantenere il pacchetto, lo affido a
qualcun altro. E questa persona cosa fece?
Inserire il codice malevolo progettato per rubare

(08:20):
criptovalute dagli utenti permisi il codice infetto,
circolò indisturbato nascosto dentro una libreria di cui tutti
si fidavano. È un caso che ci ricorda
un'altra verità. Ogni dipendenza è una porta
d'ingresso e più dipendenza abbiamo, più porte lasciamo
aperte. E non sono casi isolati.
Basti pensare alle vulnerabilitàscoperte in librerie cruciali

(08:42):
come Log for J, utilizzato praticamente da chiunque nel
mondo Java. Nel 2021 una falla critica rese
invulnerabili migliaia di sistemi in tutto il mondo,
obbligando aziende e governi a correre al riparo in tempi
record. Questi esempi ci insegnano una
cosa fondamentale. Non è la quantità di codice che
conta, ma la fiducia che riponiamo in esso.

(09:04):
Anche un piccolo pacchetto può diventare il punto debole di un
intero ecosistema ed è per questo che come sviluppatori
dobbiamo imparare a essere critici.
Non vuol dire smettere di usare librerie, sarebbe impensabile
oggi, ma vuol dire imparare a porci delle domande giuste.
Questa libreria è davvero necessaria?
È ben mantenuta e supportata da una comunità attiva?

(09:25):
Potrei scrivere io la parte che mi serve, magari in poche righe,
invece. Importare un pacchetto esterno.
La consapevolezza parte da qui, perché ogni dipendenza che
scegliamo, come abbiamo detto, non è solo un pezzo di codice in
più, è una responsabilità che ciassumiamo.
E con questa riflessione arriviamo alla conclusione della
puntata, le dipendenze software sono strumenti potenti, ci

(09:46):
permettono di risparmiare tempo,semplificare lo sviluppo e
accedere a funzionalità complesse e senza doverlo
riscrivere da zero. Ma come abbiamo visto dagli
esempi di left Padd, Heaven Stream e Log for J, anche un
piccolo pacchetto può trasformarsi in un rischio se
non siamo consapevoli di cosa stiamo importando nel nostro
progetto. La vera lezione è questa, non si

(10:06):
tratta di smettere di usare librerie, ma di imparare a farlo
con giudizio. Chiediamoci sempre, è davvero
necessaria e affidabile? Posso gestire io quella parte di
codice? Saper rispondere a queste
domande non ci rende soltanto programmatori più efficienti ma
anche più responsabili, capaci di costruire software robusto,
sicuro e sostenibile nel tempo. Questa è la scelta che distingue

(10:28):
chi programma solo per ottenere risultati immediati da chi
programma con consapevolezza, guardando anche al futuro del
proprio lavoro. Grazie per avermi dedicato parte
del vostro tempo. Vi aspetto al prossimo episodio.