Pagina 2 di 2
Legacy code, nel mio lessico, è qualsiasi codice in produzione che produce valore ma che nessuno nel team osa toccare. Non è necessariamente vecchio: può essere un'applicazione Laravel di tre anni fa scritta male, così come un gestionale PHP del 2008. Il denominatore comune è il rischio percepito di romperlo.
In questa categoria scrivo di come si interviene sul legacy: assessment iniziale, identificazione delle zone ad alto rischio, introduzione graduale di test, refactoring chirurgico, audit di sicurezza (il legacy è spesso un colabrodo di vulnerabilità), migrazione di versione PHP. Il tutto con l'obiettivo di ridurre il rischio operativo mantenendo il business in funzione.
Se hai una codebase legacy che rallenta l'azienda o che genera paura ogni volta che va modificata, parliamone: un assessment strutturato è il primo passo per recuperare il controllo. Oppure scopri come affronto i progetti legacy.
Il legacy non è un problema tecnico. È un problema di coraggio. La tecnica serve a dare strumenti a chi quel coraggio ce l'ha.
Un gestionale PHP legacy con 23.000 righe e zero test: ogni modifica rompeva qualcosa in un altro punto dell'applicazione. Ho introdotto characterization test con PHPUnit in una settimana - senza riscrivere una riga di codice applicativo - e il tasso di bug in produzione è sceso del 70% nel primo mese. Continua a leggere
Un gestionale PHP 5.6 senza Git, senza documentazione, senza test: 147 file PHP sparsi in 23 directory, credenziali MySQL hardcodate in 9 file, deploy via FTP e lo sviluppatore sparito da sei mesi. Come ho ripreso il controllo in 30 giorni con PHPStan baseline, Rector e Git incrementale. Continua a leggere
Dopo aver recuperato server e credenziali, resta il problema vero: 85.000 righe di codice Laravel senza documentazione, zero test, business logic nei Blade template, e un titolare che deve sapere entro venerdì cosa può rompere e cosa si può toccare. Il metodo in 48 ore: scansione automatica con PHPStan, mappatura rotte, analisi schema, tracciamento flusso di business e consegna di una mappa di rischio prioritizzata. Continua a leggere
Un'applicazione Laravel abbandonata da due anni su PHP EOL non si affronta in emergenza: va mappata sistematicamente prima di toccarla. Il caso reale di un gestionale interno per una catena di cliniche dentistiche veronesi del 2025, il metodo in dodici giorni con cui ho prodotto documentazione viva partendo da zero, e gli strumenti di static analysis che rendono il reverse engineering effettivamente economico. Continua a leggere
