Un ente che eroga formazione e servizi su salute, sicurezza e ambiente gestisce corsi, scadenze e valutazioni del rischio con un applicativo nato nel 2008 e cresciuto per aggiunte. Dentro ci sono anni di regole di legge codificate — D.Lgs 81/08, Accordi Stato-Regioni, calcoli del rischio. La domanda era: si riscrive? La risposta onesta è no. Ecco perché, e cosa abbiamo fatto invece.
01Perché "riscriviamo da zero" era la risposta sbagliata
La tentazione, davanti a un applicativo vecchio, è buttarlo e rifarlo. Ma qui il valore non è nell'interfaccia: è nelle regole normative codificate lato server — la valutazione del rischio, i requisiti dei corsi per mansione, le scadenze di legge. Sono regole con valore legale, scritte nel codice negli anni, senza test e senza specifiche. Riscriverle al buio non è modernizzare: è reintrodurre errori dove un errore ha conseguenze legali.
02Cosa dicono i fatti del codice
Il censimento ha fotografato la situazione reale: un client Java desktop di centinaia di migliaia di righe (solo interfaccia, salvo quattro sacche di logica ben identificate) e un server con il vero valore — il livello che calcola e applica le regole. I due sono saldati insieme: parlano un protocollo datato e non-standard (XML-RPC, ormai a fine vita) scambiandosi oggetti Java serializzati. Non esiste un'API neutra: nessun client web, nessun altro linguaggio può parlare quel protocollo.
E i problemi che nessuno aveva mai cercato: password in MD5 su dati sanitari (un tema GDPR art. 9), segreti in chiaro, librerie a fine vita, un framework di persistenza proprietario e a sorgenti chiusi (rischio uomo-chiave), distribuzione solo Windows a 32 bit, e nessun test automatico — cioè nessuna rete di sicurezza per qualunque modifica.
03La direzione: tieni il cervello, rifai la consegna
La strada scelta non è la riscrittura, è lo Strangler Fig: si strangola il vecchio un pezzo alla volta, non lo si abbatte.
In concreto: si tiene il cervello (il livello che calcola le regole, i dati, il database), gli si mette davanti un'API REST vera e neutra accanto al vecchio protocollo, e si rifà il client come web un'area funzionale alla volta. Il vecchio protocollo e la vecchia interfaccia si spengono per ultimi, solo a migrazione completata.
04Il rischio confinato dove si può gestire
Il vantaggio dello Strangler è dove non tocca: il core normativo — le regole con valore legale — resta al suo posto, provato dagli anni d'uso. Il cambiamento vive sul perimetro (l'API e l'interfaccia), che è la parte sostituibile senza perdita di regole. E la mappa completa "schermata → servizio → regola → tabella" esiste già dal censimento: la specifica della futura API non va reinventata al buio, si legge da lì.
Le quattro sacche di logica rimaste nel client — calcoli che il server non replica — si spostano lato server come primo passo, così l'interfaccia diventa davvero sostituibile senza portarsi via una regola.
05Si parte da un pilota
Un progetto così non si fa in un colpo: si comincia da un'area piccola e autocontenuta, la si porta sul nuovo binario (API + web) accanto al vecchio, e la si usa davvero. È il modo per validare l'approccio sul campo prima di allargarlo, e per far emergere i problemi quando costano poco. Nel frattempo si sistemano, durante il lavoro sull'API, le cose che non possono aspettare: l'MD5 sui dati sanitari, i segreti in chiaro, le librerie a fine vita.
06Cosa abbiamo imparato
1. Il valore di un gestionale legacy è spesso invisibile. Non è l'interfaccia che si vede: sono le regole di legge scritte nel codice. Quelle si conservano, non si riscrivono al buio.
2. Misurare chiude le incognite. Il censimento completo del codice ha trasformato "chissà cosa c'è dentro" in una lista chiusa e piccola.
3. Strangler batte big-bang quando c'è un core con valore legale: rischio confinato al perimetro, progetto incrementale e reversibile.
4. La sicurezza si sistema strada facendo. MD5 su dati sanitari e segreti in chiaro non aspettano la fine del progetto: si chiudono mentre si costruisce l'API.