Pagina 2 di 5
Refactoring non è riscrivere tutto da capo. È il lavoro meno appariscente e più prezioso che uno sviluppatore senior possa fare: trasformare una codebase confusa, fragile o lenta in qualcosa di leggibile e testabile, tenendola in produzione mentre la modifichi. In questa categoria raccolgo il metodo con cui si interviene su codice reale, quello che le PMI hanno davvero, non quello dei tutorial.
Il primo tema è il 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.
Il secondo tema è 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 vero rischio. La metrica che conta è sempre il rischio di regressione, e l'approccio è incrementale, misurabile e reversibile, così che il software funzioni come prima ma diventi finalmente modificabile.
Il terzo tema è il debito tecnico come questione aziendale. Il debito non è un problema estetico da sviluppatori: ha un costo che si può calcolare e presentare al management, ed è una scelta strategica decidere quando pagarlo. 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 su VPS OVH, il freelance sparito da tre mesi, credenziali perse, nessun backup del codice e il certificato SSL in scadenza tra 8 giorni. Le prime 48 ore di un subentro d'emergenza: mappatura accessi, backup immediato, rotazione credenziali e stabilizzazione prima di qualsiasi modifica. Continua a leggere
Un gestionale PHP legacy dove gli errori si scoprivano dalle telefonate dei clienti: nessun log strutturato, nessun alert, MTTR medio di 4 ore. Ho introdotto Monolog con output JSON, metriche operative con cron e alert Telegram in 5 giorni - senza riscrivere una riga di codice applicativo. MTTR sceso a 22 minuti. Continua a leggere
Un gestionale PHP 7.0 ereditato da un freelance sparito: 43.000 righe di codice, nessuna documentazione, e il titolare che deve decidere se investire nella modernizzazione o riscrivere da zero. In 30 giorni ho prodotto un audit completo con PHPStan, Psalm, analisi delle dipendenze e una roadmap di intervento con costi e priorità. Continua a leggere
Un gestionale PHP 5.6 con 23.000 righe, zero test e debito tecnico che rendeva ogni modifica un rischio: il cliente pagava il triplo per ogni nuova funzionalità rispetto a un'applicazione moderna. In tre mesi di refactoring incrementale con Strangler Fig Pattern, PHPStan e Rector l'ho reso manutenibile senza riscrivere una riga da zero. Continua a leggere
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 su VPS OVH con deploy via FTP: il titolare aveva perso due giorni di lavoro sovrascrivendo un file in produzione senza backup. Ho implementato Git con bare repository e post-receive hook, deploy in un comando e rollback in 10 secondi. Da FTP a Git in 5 giorni senza un minuto di downtime. 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
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
Tool gratuiti per analizzare il codice esistente:
