Il tuo team evita di deployare il venerdì. E spesso anche il giovedì. Ogni rilascio, cioè ogni pubblicazione di una nuova versione del software, è preceduto da test manuali, mail di avvertimento e qualcuno che resta collegato "per sicurezza". È il segnale di un software fragile, dove ogni modifica rischia di causare una regressione. E quella fragilità ha un costo che stai pagando ogni giorno.
I segnali del software fragile
Si riconoscono anche senza essere tecnici.
Correggi un bug nel carrello e si rompe la fatturazione. Aggiungi un campo al form di registrazione e smette di funzionare il reset password. Alcune parti del codice vengono evitate perché “funzionano, meglio non toccarle”.
Questi sono bug di regressione: modifiche in un punto che causano rotture in punti apparentemente non collegati.
I segnali concreti sono abbastanza chiari: deploy che richiedono ore di test manuali prima di andare in produzione, moduli che nessuno vuole modificare, bug segnalati su funzionalità che non sono state toccate, hotfix che generano altri hotfix e tempi molto lunghi anche per modifiche che in teoria sembrano semplici. Se riconosci diversi di questi sintomi, il sistema sta diventando fragile.
Perché succede
Il software raramente nasce fragile. Lo diventa nel tempo.
Pochi test automatici sui flussi critici
Senza test automatici, ogni modifica diventa un azzardo. Nessuno sa con certezza cosa si romperà finché qualcuno non se ne accorge in produzione.
Come ho scritto parlando di test coverage, non serve testare tutto. Ma serve testare i percorsi che contano davvero per il business.
Alto accoppiamento tra le parti del sistema
Quando ogni modulo dipende da molti altri, toccare un punto significa rischiare di avere effetti collaterali altrove. Questo succede quando il codice cresce senza una separazione chiara delle responsabilità.
Debito tecnico accumulato
Le scorciatoie ripetute nel tempo rendono il sistema sempre più difficile da modificare. Il debito tecnico non si vede nei report, ma si manifesta in lentezza, bug e timore di intervenire.
Il costo per il business
La fragilità ha un impatto economico molto concreto. Se ogni deploy è rischioso, si rilascia meno spesso e le funzionalità arrivano ai clienti più lentamente. I bug che sfuggono in produzione costano fiducia, supporto e reputazione. Nel frattempo il team entra in un blocco psicologico: chi ha paura di modificare il codice smette di proporre miglioramenti, e le persone migliori tendono a cercare contesti meno stressanti. Quando perdi persone chiave, la situazione peggiora ancora. Anche il costo delle modifiche cresce: un intervento che in un sistema sano richiederebbe due giorni, in un sistema fragile può richiederne dieci.
A questo punto spesso nasce la tentazione di riscrivere tutto da zero. Raramente è la scelta migliore.
Come migliorare senza fermare lo sviluppo
Non serve bloccare il progetto per mesi. Conviene intervenire in modo graduale e continuo.
Conviene partire dai flussi critici: registrazione, login, pagamento, operazioni core. Anche pochi test ben scritti su questi percorsi riducono drasticamente le regressioni. Poi si lavora un modulo alla volta: ogni volta che si interviene su un pezzo di codice, lo si lascia un po’ più ordinato e indipendente di come lo si è trovato. È un miglioramento progressivo, non un refactoring massivo.
Ha molto valore anche automatizzare la pipeline di rilascio. Build automatiche, test automatici e un ambiente di staging affidabile riducono il rischio e trasformano il deploy in un’operazione ordinaria. Anche l’AI può aiutare, ma solo se le fondamenta sono abbastanza sane da permetterlo.
Infine conviene misurare la fragilità con pochi indicatori chiari: numero di bug di regressione al mese, tempo medio tra commit e deploy, numero di rollback, cioè ritorni rapidi alla versione precedente, dopo un rilascio. Se questi numeri migliorano, la fragilità sta davvero diminuendo.
La regola pratica
Se il tuo team ha paura di deployare, il problema è nel sistema.
E il sistema tende a peggiorare nel tempo se non si interviene. Basta iniziare: qualche test mirato, una pipeline più solida, una conversazione chiara sulle parti più rischiose del codice.
Un sistema sano permette di rilasciare spesso, con serenità. Quando questo non succede, è un segnale che vale la pena ascoltare.
Simone Giusti
Consulente software strategico
