Il tuo team evita di deployare il venerdì. E spesso anche il giovedì. Ogni rilascio è 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 da osservare:
- 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
- Tempi molto lunghi anche per modifiche che sembrano semplici
Se riconosci diversi di questi punti, 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 è un avoiding. 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à non è un problema tecnico. È un problema economico.
Velocità di rilascio ridotta. Se ogni deploy è rischioso, si deploya meno spesso. Le funzionalità arrivano ai clienti più lentamente.
Bug in produzione. I bug che arrivano ai clienti costano fiducia, supporto e reputazione.
Blocco psicologico del team. Un team che ha paura di modificare il codice smette di proporre miglioramenti. Le persone migliori tendono a cercare contesti meno stressanti. E quando perdi persone chiave, la situazione peggiora.
Costo crescente delle modifiche. Una modifica 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. Si può intervenire in modo graduale.
Testare prima i flussi critici
Inizia da registrazione, login, pagamento, operazioni core. Anche pochi test ben scritti su questi percorsi riducono drasticamente le regressioni.
Migliorare un modulo alla volta
Ogni volta che si interviene su un pezzo di codice, lo si può lasciare un po’ più ordinato e indipendente di come lo si è trovato. È un miglioramento progressivo, non un refactoring massivo.
Automatizzare la pipeline di rilascio
Build automatiche, test automatici, ambiente di staging affidabile. CI/CD riduce il rischio e trasforma il deploy in un’operazione ordinaria.
Anche l’AI può aiutare, ma solo se le fondamenta sono sane.
Misurare la fragilità
Tre indicatori semplici:
- Numero di bug di regressione al mese
- Tempo medio tra commit e deploy
- Numero di rollback dopo un rilascio
Se questi numeri migliorano, la fragilità sta 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
