Vai al contenuto

Refactoring del codice legacy: ripristinare la manutenibilità

La tua applicazione funziona. È in produzione da anni e serve utenti reali. Ma lavorare con la codebase è diventato più difficile: le modifiche richiedono più tempo del previsto, i bug compaiono in punti inaspettati e i nuovi sviluppatori faticano a capire come si incastrano le parti. Questo è il codice legacy, e per affrontarlo non serve una riscrittura completa.

Di Daniele Barbaro, Tech Lead e Software Engineer. Ultimo aggiornamento .

Approccio
Incrementale, mai una riscrittura totale
Passi
Piccoli e reversibili
Il tuo team
Lavoro accanto ai tuoi sviluppatori
Formule
Giornate mirate o mensile

Come si presenta un refactoring in pratica

Non credo nelle riscritture big bang. Sono rischiose, costose e spesso non necessarie. Pratico il refactoring incrementale: miglioro la codebase passo dopo passo, mentre il sistema resta in funzione e continua a generare valore.

Ogni passo lascia il sistema in uno stato funzionante, e il tuo team continua a rilasciare funzionalità mentre io miglioro le fondamenta su cui sta costruendo.

app/Http/Controllers/ContestController.php+6 -10
@@ -9,17 +9,13 @@ class ContestController extends Controller {rimossa: public function register(Request $request, Contest $contest)aggiunta: public function register(RegisterToContestRequest $request, RegisterToContestAction $action) {rimossa: $request->validate([/* 15 rules */]); if ($contest->registrations()->count() >= $contest->max_participants) { return back()->withErrors(['contest' => 'Full']); } $user = User::firstOrCreate(['email' => $request->email], [...]); $registration = $contest->registrations()->create([...]); Mail::to($user)->send(new RegistrationConfirmed($registration));aggiunta: $action->execute( $request->contest(), new RegistrationData(...$request->registrationData()), $request->user(), ); return redirect()->route('thanks'); } }
Stessa rotta, stessa risposta. La validazione passa a una form request, le query e l'email a un'action. Dal mio codice Laravel, accorciato.

Cosa rende il codice "legacy"

Il codice legacy non è semplicemente codice vecchio. Il codice diventa legacy quando resiste al cambiamento, quando il costo di una modifica supera quello che sembra ragionevole per il compito da svolgere. Succede per molte ragioni.

Decisioni tecniche accumulate
Ogni codebase riflette il contesto in cui è stato costruito. Le versioni dei framework cambiano, le best practice si evolvono e i requisiti di business si spostano. Decisioni sensate cinque anni fa possono creare attrito oggi, perché l'architettura era pensata per una scala diversa, un team diverso o una comprensione diversa del problema.
Test mancanti o inadeguati
Senza test, le modifiche diventano rischiose. Gli sviluppatori lavorano più lentamente, temendo di rompere qualcosa che non riescono a vedere. Questa paura porta a soluzioni tampone invece che a correzioni vere, e la codebase accumula strati di codice difensivo che offuscano l'intento originale.
Perdita di conoscenza
I membri del team se ne vanno, la documentazione invecchia e la conoscenza tribale scompare. Alcune parti del sistema diventano scatole nere che tutti temono di toccare. Il codice funziona, ma nessuno capisce più fino in fondo perché o come.
Crescita organica senza design
Le applicazioni di successo crescono. Le funzionalità vengono aggiunte sotto la pressione delle scadenze, i casi limite si gestiscono con soluzioni rapide e le integrazioni vengono innestate ovunque ci sia spazio. Con il tempo, l'architettura emersa smette di servire le reali esigenze dell'applicazione.

Come lavoro, passo dopo passo

Quattro abitudini guidano ogni intervento di refactoring.

Capire prima di modificare
Ogni intervento inizia con uno studio attento del sistema esistente. Leggo il codice, ricostruisco i percorsi di esecuzione e mappo le dipendenze. Identifico cosa fa davvero il codice rispetto a cosa avrebbe dovuto fare. Questa comprensione guida ogni decisione successiva.
Costruire reti di sicurezza
Prima di apportare modifiche significative devo poter sapere se ho rotto qualcosa. Spesso significa aggiungere test dove non esistono: test di caratterizzazione che catturano il comportamento attuale, test di integrazione che verificano i percorsi critici e unit test che documentano il comportamento atteso man mano che procedo.
Passi piccoli e reversibili
Le modifiche ampie sono difficili da revisionare, da testare e da annullare. Lavoro per piccoli incrementi, ognuno dei quali lascia il sistema in uno stato funzionante. Se qualcosa va storto, so esattamente cosa è cambiato e posso annullarlo facilmente.
Consegna continua durante tutto il percorso
Il refactoring non deve significare mesi di lavoro prima che arrivi valore. Organizzo il lavoro in modo che i miglioramenti raggiungano la produzione con regolarità. Il tuo team continua a rilasciare funzionalità mentre io miglioro le fondamenta.

Cosa comporta il refactoring

Il lavoro specifico dipende da cosa serve alla tua codebase, ma gli schemi più comuni includono:

Estrazione delle responsabilità
Classi e metodi troppo grandi, che fanno troppe cose, vengono suddivisi in componenti mirati a responsabilità singola. Il codice diventa più facile da capire, testare e modificare.
Chiarire i confini
Quando la logica di business è dispersa tra controller, model e view, la consolido in servizi o azioni di dominio espliciti. Confini chiari rendono il sistema più facile da comprendere.
Migliorare i pattern di accesso ai dati
Query N+1, indici mancanti e caricamento dati inefficiente vengono identificati e corretti. Ottimizzo l'uso di Eloquent o Doctrine per i tuoi reali pattern di accesso.
Aggiungere copertura di test
Costruisco una suite di test che dà al tuo team la fiducia necessaria per fare modifiche. Include test ad alto livello che verificano il comportamento e unit test mirati che documentano le aspettative.
Aggiornare le dipendenze
Versioni datate dei framework e pacchetti obsoleti vengono aggiornati con attenzione. Il lavoro procede in modo incrementale, con test approfonditi a ogni passaggio.

Modernizzazione del framework

Molte codebase legacy sono costruite su versioni datate di Laravel o Symfony. Aggiornare non significa solo avere le funzionalità più recenti: significa anche patch di sicurezza, miglioramenti delle prestazioni e accesso a pratiche di sviluppo moderne.

Aggiorno applicazioni Laravel e Symfony attraverso i salti di versione major. Questo include la gestione delle API deprecate, la migrazione verso pattern più recenti come l'Eloquent strict mode o Symfony Messenger, e l'aggiornamento della codebase per sfruttare le funzionalità moderne di PHP.

Gli aggiornamenti dei framework sono sempre incrementali. Non passo da Laravel 6 a Laravel 11 in un solo passaggio. Ogni aggiornamento di versione viene isolato, testato e distribuito prima di passare al successivo. Così il rischio resta basso ed è semplice individuare e correggere qualsiasi problema.

Per chi è pensato

Il refactoring legacy ha senso per team in situazioni specifiche.

La tua applicazione ha ancora valore
Il business gira su questo codice e gli utenti dipendono da esso. Abbandonarlo non è un'opzione, e una riscrittura completa sarebbe troppo rischiosa o costosa. Devi migliorare quello che hai.
La velocità di sviluppo è calata
Funzionalità che dovrebbero richiedere giorni ora richiedono settimane. Il tuo team passa più tempo ad aggirare i problemi che a risolverli, e la codebase ostacola la tua capacità di rispondere alle esigenze del business.
Stai pianificando una crescita
Stai per assumere altri sviluppatori, entrare in nuovi mercati o costruire funzionalità nuove e significative. La codebase attuale non sosterrà quella crescita senza un investimento sulle sue fondamenta.
Il debito tecnico si sta accumulando
Ogni scorciatoia aggiunge debito, e stai pagando interessi su anni di compromessi. È il momento di iniziare a ripagarlo in modo sistematico.
L'onboarding di nuovi sviluppatori è doloroso
Ogni nuovo membro del team impiega mesi per diventare produttivo. Fa domande a cui nessuno sa rispondere e impara per tentativi ed errori quali parti della codebase evitare. Questo rallenta la crescita e aumenta il rischio.

Lavorare insieme

Il refactoring può essere strutturato come consulenza giornaliera per valutazioni mirate e miglioramenti puntuali, oppure come collaborazione mensile per interventi prolungati insieme al tuo team di sviluppo.

Lavoro insieme ai tuoi sviluppatori, non al posto loro. Il trasferimento di conoscenza è parte integrante di tutto quello che faccio. L'obiettivo è lasciare al tuo team una codebase che capisce e con cui è piacevole lavorare, oltre alle competenze per mantenerla tale.

Le mie tariffe sono pubbliche, senza moduli in mezzo: vedi la pagina delle tariffe.

Domande frequenti sul refactoring del codice legacy

Cosa rende una codebase legacy?

Il codice legacy non è semplicemente codice vecchio. Diventa legacy quando resiste al cambiamento, quando il costo di una modifica supera quello che l'attività richiederebbe ragionevolmente. Le cause tipiche sono test mancanti, decisioni prese in un contesto che non vale più, conoscenza persa con le persone uscite dal team e crescita organica senza progetto.

Riscrivi l'applicazione da zero?

No. Le riscritture complete sono rischiose, costose e quasi sempre evitabili. Il refactoring è incrementale: prima capire il sistema, poi aggiungere test di caratterizzazione come rete di sicurezza, quindi procedere per piccoli passi reversibili che lasciano sempre l'applicazione funzionante. Il tuo team continua a rilasciare funzionalità.

Come aggiorni un'applicazione Laravel o Symfony tra versioni major?

Una versione alla volta. Non si passa da Laravel 6 a Laravel 11 in un solo salto. Ogni aggiornamento di versione viene isolato, testato e rilasciato prima di iniziare il successivo: così il raggio d'azione resta ridotto e qualsiasi regressione è attribuibile a una modifica precisa.

In cosa consiste il lavoro di refactoring?

Estrarre classi troppo grandi in componenti con una responsabilità chiara, consolidare la logica di business sparsa tra controller e model in domain service espliciti, correggere query N+1 e indici mancanti, costruire copertura di test dove serve davvero e aggiornare dipendenze obsolete. Il mix dipende da cosa serve alla codebase.

Come viene fatturato il refactoring?

Valutazioni mirate e interventi circoscritti seguono la consulenza a giornata. Il refactoring continuativo insieme al tuo team di sviluppo segue la collaborazione mensile da 12 o 16 giornate al mese, con un costo giornaliero più basso rispetto alle giornate prenotate una per una. Le tariffe sono nella pagina delle tariffe.

Come iniziare

Se la tua applicazione funziona ma la codebase diventa sempre più difficile da modificare, raccontamelo. Vorrò capire cosa ti rallenta e quali parti nessuno vuole toccare.

Non sai quanto lavoro serve? Un audit della codebase è un buon primo passo: una valutazione indipendente dello stato dell'applicazione.

Fissiamo una call (si apre in una nuova scheda)

me@plincode.tech

A TorinoToolbox Coworking (si apre in una nuova scheda)
via Agostino da Montefeltro 2
Torino, TO 10134

La porta è sempre aperta per un caffè e due chiacchiere.