Pagina 2 di 3
Refactoring non è riscrivere tutto da capo. È il lavoro meno glamour e più prezioso che uno sviluppatore senior può fare: trasformare una codebase confusa, fragile o lenta in qualcosa di leggibile, testabile e pronto a crescere — mantenendola in produzione mentre la modifichi. Lo faccio da anni su progetti PHP/Laravel di clienti che non possono permettersi un rewrite.
In questa categoria scrivo di tecniche di refactoring applicate: come intervenire su metodi lunghi centinaia di righe, come introdurre test in codice non testato, come estrarre servizi senza rompere le dipendenze, come riconciliare controller obesi o modelli Eloquent che fanno troppo. Il tutto con l'attenzione al rischio di regressione, che è la vera metrica di successo.
Se hai una codebase che rallenta il team, aumenta i bug o rende rischioso ogni rilascio, parliamone: posso fare un assessment e definire un percorso di refactoring incrementale. Oppure scopri come lavoro.
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 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
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
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
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
Il software legacy rappresenta una minaccia concreta alla sicurezza, all'efficienza e alla competitività delle PMI italiane. In questo redazionale approfondito, scoprirai perché ignorarlo è pericoloso, e come una strategia di refactoring mirata con Laravel può trasformare un rischio in un'opportunità, guidata dall'esperienza di un professionista con 20 anni di carriera nel PHP e Laravel. Continua a leggere
Il refactoring del codice legacy, specialmente in PHP, non è solo un intervento tecnico: è una strategia aziendale essenziale per evitare vulnerabilità di sicurezza, ridurre costi nascosti e migliorare significativamente le performance operative. Scopri perché modernizzare il codice significa investire nella crescita a lungo termine della tua azienda. Continua a leggere
Il PR #6188 "Slim skeleton" di Taylor Otwell ha rimosso AuthorizesRequests e ValidatesRequests dal Controller base di Laravel 11. La motivazione: "$this->validate has not been documented in some time. $this->authorize can simply be Gate::authorize." Le Form Request (introdotte in Laravel 5.0, febbraio 2015) e il facade Gate sostituiscono i trait impliciti con composizione esplicita - il principio "favor composition over inheritance" del Gang of Four applicato al framework. Continua a leggere
Robert C. Martin definisce il Single Responsibility Principle come "un modulo deve essere responsabile verso un solo attore". Un controller Laravel che valida input, calcola totali, aggiorna stock, crea record e invia notifiche ha almeno cinque motivi per cambiare. Il Service Layer (Fowler, PoEAA) e l'Action pattern (Freek Van der Herten) estraggono la logica di business dal controller, e il Service Container di Laravel la rende iniettabile e testabile in isolamento. Continua a leggere
L'Health Routing di Laravel, introdotto in Laravel 11 (PR #47309), espone un endpoint /up che dispatcha l'evento DiagnosingHealth - i listener che lanciano eccezioni causano HTTP 500, altrimenti HTTP 200. È un check pass/fail per load balancer e Kubernetes probes. Per monitoring dettagliato con dashboard e notifiche, spatie/laravel-health (10M+ install) offre 16+ check integrati. AWS Builders' Library documenta il trade-off tra shallow e deep health check. Continua a leggere
