Categoria

Pagina 3 di 3

Refactoring: migliorare il codice esistente senza rompere il business

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.

L'helper once() in Laravel 12: memoizzazione per-request con WeakMap al posto di proprietà statiche e cache forzata

L'helper once() in Laravel 12: memoizzazione per-request con WeakMap al posto di proprietà statiche e cache forzata L'helper once(), introdotto in Laravel 11 (PR #49744, Nuno Maduro), usa internamente una WeakMap di PHP 8.0 per cachare il risultato di una closure per la durata della request. In metodi d'istanza la cache è per-oggetto, in metodi statici è per-classe, in contesto globale è per call-site. In Octane, FlushOnce esegue Once::flush() tra le request. Continua a leggere
Ultima modifica:

Event discovery in Laravel 12: da EventServiceProvider a auto-discovery per listener disaccoppiati e testabili

Event discovery in Laravel 12: da EventServiceProvider a auto-discovery per listener disaccoppiati e testabili L'event discovery scansiona automaticamente i listener nella directory app/Listeners e li registra in base al type-hint del metodo handle(). Introdotto in Laravel 5.8.9 come opt-in, è diventato il default da Laravel 11 con la rimozione dell'EventServiceProvider dallo skeleton. Il risultato: zero configurazione manuale, listener auto-registranti e testabili con Event::fake(). Continua a leggere
Ultima modifica:

Strategy pattern in Laravel: selezione dinamica di implementazioni con Service Container, contextual binding e Pennant

Strategy pattern in Laravel: selezione dinamica di implementazioni con Service Container, contextual binding e Pennant Lo Strategy pattern - un behavioral pattern del Gang of Four - in Laravel si implementa con il Service Container: bind() per il default, when()->needs()->give() per eccezioni contestuali, e Feature::active() di Pennant per switching runtime basato su feature flag. Nessuna factory custom necessaria. Continua a leggere
Ultima modifica:

Validazione in Laravel 12: da closure inline a Rule Objects con ValidationRule per regole testabili, riutilizzabili e type-safe

Validazione in Laravel 12: da closure inline a Rule Objects con ValidationRule per regole testabili, riutilizzabili e type-safe L'interfaccia ValidationRule, introdotta in Laravel 10, ha sostituito la vecchia Rule con passes()/message() e InvokableRule, entrambe deprecate. Un unico metodo validate() con closure $fail permette regole testabili in isolamento, parametrizzabili via costruttore, e riutilizzabili su più Form Request senza duplicazione. Continua a leggere
Ultima modifica:

Concurrency::run() in Laravel: esecuzione parallela di task I/O-bound senza code, worker o estensioni pcntl

Concurrency::run() in Laravel: esecuzione parallela di task I/O-bound senza code, worker o estensioni pcntl Concurrency::run() è stato introdotto in Laravel 11.23 e stabilizzato in Laravel 12. Il driver process (default) serializza le closure, le esegue in processi PHP figli separati via Artisan, e restituisce i risultati al processo padre. Non usa fibers né thread - ogni task ha il proprio bootstrap completo dell'applicazione. Continua a leggere
Ultima modifica:

Testing dei job in coda Laravel: da Queue::fake() a withFakeQueueInteractions() per validare retry, release e failure senza broker

Testing dei job in coda Laravel: da Queue::fake() a withFakeQueueInteractions() per validare retry, release e failure senza broker Queue::fake() verifica che un job venga dispatchato correttamente, ma non testa cosa succede dentro handle() quando il job deve rilasciarsi, cancellarsi o fallire. withFakeQueueInteractions(), introdotto in Laravel 11, permette di chiamare handle() in isolamento e asserire su release(), delete() e fail() senza un broker reale. Continua a leggere
Ultima modifica:

Modernizzare i Model Eloquent Laravel: guida al refactoring da $casts array (L9/L10) al potente metodo casts() in Laravel 12

Modernizzare i Model Eloquent Laravel: guida al refactoring da $casts array (L9/L10) al potente metodo casts() in Laravel 12 La proprietà $casts non è deprecata in Laravel 12, ma il metodo casts() introdotto in Laravel 11 abilita chiamate statiche come AsEnumCollection::of() e AsCollection::using() - impossibili in una definizione di proprietà PHP. Ecco quando e come migrare. Continua a leggere
Ultima modifica:

Refactoring applicazione Laravel 10: guida passo-passo per adottare la struttura snella di Laravel 12 e centralizzare la configurazione

Refactoring applicazione Laravel 10: guida passo-passo per adottare la struttura snella di Laravel 12 e centralizzare la configurazione Laravel 11 ha introdotto la struttura slim che elimina Http/Kernel, Console/Kernel e la maggior parte dei Service Provider, centralizzando tutto in bootstrap/app.php. La guida ufficiale dice che la migrazione non è obbligatoria - ma in un applicativo con logica custom sparsa tra Kernel e Provider, adottarla riduce il boilerplate e la superficie di manutenzione. Continua a leggere
Ultima modifica:

Feature flag in Laravel: modernizzare la gestione da approcci custom L9/L10 a Laravel Pennant per applicazioni aziendali scalabili in L12

Feature flag in Laravel: modernizzare la gestione da approcci custom L9/L10 a Laravel Pennant per applicazioni aziendali scalabili in L12 Le feature flag gestite con config() e tabelle custom generano debito tecnico che cresce con ogni funzionalità aggiunta. Laravel Pennant offre definizioni class-based, scoping per utente o tenant, rollout percentuali e un'API di testing che semplifica la migrazione da approcci legacy. Continua a leggere
Ultima modifica:

Refactoring di moduli business-critical in gestionali PHP legacy: strategie con Laravel e Symfony per la stabilità

Refactoring di moduli business-critical in gestionali PHP legacy: strategie con Laravel e Symfony per la stabilità Molti gestionali PHP delle PMI italiane soffrono di codice legacy datato e difficile da manutenere. Moduli critici come fatturazione e gestione clienti diventano colli di bottiglia. Questo articolo esplora strategie di refactoring con Laravel e Symfony, mostrando come i test automatici con PHPUnit e Pest trasformino questa sfida in un investimento sicuro per stabilità ed efficienza. Continua a leggere
Ultima modifica: