Pagina 3 di 5
Fare refactoring vuol dire trasformare una codebase confusa, fragile o lenta in qualcosa di leggibile e testabile, tenendola in produzione mentre la modifichi. È il lavoro meno appariscente che uno sviluppatore senior possa fare, e uno dei più utili. In questa categoria raccolgo il metodo con cui si interviene su codice reale, quello che le aziende hanno davvero, lontano dagli esempi dei tutorial.
Spesso si parte dal subentro sull'ignoto. Molto del mio lavoro comincia con una base ereditata, senza documentazione, spesso dopo la sparizione dello sviluppatore originale: migliaia di righe da capire, credenziali da recuperare, un business che intanto deve continuare a girare. Scrivo del metodo per mappare in pochi giorni cosa hai davanti, del reverse engineering sistematico e del protocollo delle prime ore quando la situazione è un'emergenza.
Poi viene la modernizzazione senza rotture: portare avanti una base PHP legacy o un framework fuori supporto attraverso le versioni, gestendo i cambi di comportamento silenziosi, che sono il rischio più insidioso. La metrica che conta è il rischio di regressione, e l'approccio è incrementale, misurabile e reversibile, così che il software funzioni come prima ma diventi finalmente modificabile.
Infine il debito tecnico come questione aziendale. Il debito ha un costo che si può calcolare e presentare al management, e decidere quando pagarlo è una scelta strategica. Racconto come si porta questa conversazione fuori dal reparto tecnico, dove le decisioni si prendono davvero.
Se hai una codebase che rallenta il team, vedi la consulenza IT e DevOps o parliamone.
Il refactoring ben fatto si vede dal fatto che nessuno se ne accorge: il software funziona come prima, ma adesso si può toccare senza paura.
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
Una PMI ligure con e-commerce Laravel su OVH VPS pagava 89€/mese per un server con problemi di I/O ricorrenti. Ho migrato tutto su Hetzner CPX31 a 16€/mese con rsync incrementale, replica MySQL e cutover DNS in finestra notturna. Zero downtime, zero ordini persi, metà del costo. Il protocollo operativo che uso per ogni migrazione VPS tra provider. 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
Il gestionale logistico più critico di un'azienda piemontese di distribuzione alimentare non aveva test, non aveva pipeline, e i deploy si facevano via FileZilla il venerdì sera. In tre settimane ho portato il team da zero automazione a una pipeline GitHub Actions con PHPStan livello 5, Pest su 340 test, deploy atomico via webhook e rollback in 90 secondi. 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
Quando lo sviluppatore originale è scomparso e il server VPS unmanaged è bloccato, il provider non risolve il problema al posto tuo: ti consegna gli strumenti - rescue mode, console KVM, log di sistema - ma sta a te (o a chi ti aiuta) usarli nel modo giusto. Il caso reale di un Hetzner AX41 lockato del cliente romano del 2025 e i comandi esatti che ho usato per recuperarlo in tre ore di lavoro. Continua a leggere
L'emergenza è passata, il sito gira di nuovo, gli accessi sono recuperati. Adesso cominciano i 90 giorni decisivi: o il debito tecnico viene misurato, prioritizzato e ripagato in modo strutturato, o tornerai a spegnere esattamente lo stesso incendio fra sei mesi. Il piano che applico nei tre mesi successivi a un subentro su server Hetzner o OVH, con metriche concrete, cadenza mensile e budget realistico per una PMI italiana che non ha un team DevOps dedicato. Continua a leggere
Quando lo sviluppatore sparisce e il business dipende da un'applicazione PHP su Hetzner, OVH o Aruba, le prime 72 ore decidono se il subentro va liscio o diventa un disastro. Il protocollo che applico: inventario accessi strutturato, recupero credenziali con i provider, codebase forensics su Git, stop-the-bleeding chirurgico e mappa del debito tecnico ereditato. Cinque fasi sequenziali con comandi concreti per riprendere il controllo di un progetto orfano. Continua a leggere
La differenza fra senior e junior non è il numero di anni: è un set di abitudini operative misurabili. Definition of done estesa, lettura prima di scrittura nel rapporto 10:1, refactoring incrementale del 10% per PR, KISS sopra cleverness, ADR scritti come codice di prima classe, regole non negoziabili su Git e migrazioni. Sei abitudini che difendo in ogni code review PMI e che abbattono il debito tecnico in modo misurabile nei tre-quattro mesi successivi. Continua a leggere
Ignorare il refactoring del codice legacy limita crescita e sicurezza aziendale. Scopri perché questa attività è fondamentale per migliorare performance, ridurre rischi e garantire la competitività futura della tua azienda. Continua a leggere
Tool gratuiti per analizzare il codice esistente:
