Pagina 2 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.
La 'riscrittura totale' è quasi sempre un errore. Con il pattern Strangler Fig ho aiutato una società logistica a estrarre gradualmente funzionalità dal loro monolite Laravel: prima il modulo di tracking, poi la fatturazione. Due anni dopo, tre microservizi autonomi e il monolite ridotto del 40%, sempre in produzione. Continua a leggere
Modernizzare un'applicazione PHP 7.4 a PHP 8.3 non significa riscrivere tutto - significa sfruttare le nuove feature dove migliorano la leggibilità e la sicurezza. Vi mostro il processo che uso: identificare i candidati giusti per match expression e named arguments, refactoring sicuro con test a tappeto. Continua a leggere
Ho ereditato un'API Laravel usata da 40 integratori terzi senza versioning. Aggiungere un campo obbligatorio era un problema diplomatico prima che tecnico. Vi mostro le strategie di versioning che ho adottato, come ho introdotto il versioning retroattivamente e il contratto di deprecation che uso con i clienti API. Continua a leggere
Un gestionale PHP legacy con zero test e 3 regressioni al mese: ogni fix rompeva qualcosa. In 5 giorni ho introdotto 28 smoke test HTTP e 12 snapshot test sulle funzioni di calcolo - senza toccare il codice applicativo. Regressioni in produzione scese da 3/mese a zero nel primo trimestre. Continua a leggere
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
Tool gratuiti per analizzare il codice esistente:
