Rimettere in sesto un front-end cresciuto troppo in fretta

Esiste un tipo di codebase che hanno solo i prodotti di successo. Ha rilasciato in fretta, ha conquistato clienti, e a ogni sprint qualcuno ha attaccato una funzionalità nuova al primo pezzo di codice che capitava a tiro. Tre anni dopo il prodotto va benissimo — e il front-end è una casa infestata. Ogni sviluppatore ha un'ala in cui si rifiuta di entrare.

Se la scena ti suona familiare: congratulazioni, e condoglianze. Questo è il metodo che uso quando un team mi chiama esattamente in quel momento.

Primo: dare un nome al problema vero

"Debito tecnico" è una diagnosi inutile: indica tutto, quindi non indica niente. In pratica, i front-end cresciuti di corsa fanno male quasi sempre negli stessi punti:

Lo stato vive ovunque. Cache del server, store globale, stato dei componenti e URL raccontano ognuno una verità diversa.
I componenti fanno troppo. Il componente da 900 righe che scarica dati, li trasforma, disegna l'interfaccia e gestisce la navigazione — importato in undici punti diversi.
Ogni autore ha il suo stile. Tre modi di chiamare le API, quattro di gestire gli errori, due strutture di cartelle in competizione — a seconda di chi ha scritto quel pezzo e in che anno.
Nessuno si fida di una modifica. Mancano i test dove servirebbero davvero, e ogni rilascio diventa un piccolo atto di coraggio.

Prima di rifattorizzare qualsiasi cosa, dedica una settimana a misurare: dove si concentrano i bug? Quali file vengono toccati in ogni singola feature? Quella mappa — frequenza di modifica × densità di difetti — ti dice dove sta la leva. Di solito sono 4–6 file, non quattrocento.

Le regole d'ingaggio

Niente rewrite. Un rewrite scambia problemi che conosci con problemi che non conosci ancora, e congela la roadmap mentre li riscopri uno a uno. L'azienda che ha finanziato la tua crescita non finanzierà un anno di "niente di nuovo, ma dentro è tutto più bello, promesso".

La regola del boy scout non è una strategia. "Lascia il codice meglio di come l'hai trovato" produce atti di ordine casuali. Il miglioramento deve seguire la mappa della leva, non l'umore dello sviluppatore.

Ogni passo arriva in produzione. Se un refactoring non può essere rilasciato da solo, è troppo grande. Riducilo finché non può esserlo.

Il metodo

1. Fermare l'emorragia

Prima di migliorare qualcosa, smetti di peggiorarlo. Concorda con il team un solo pattern di riferimento per i quattro grandi temi — recupero dati, stato, gestione errori, struttura delle cartelle — e fallo rispettare solo sul codice nuovo, in review e con regole di lint. Il codice vecchio per ora non si tocca. Costa quasi zero e divide subito la codebase in "legacy" e "via d'uscita".

2. Costruire la strada asfaltata

Prendi la cosa che il team costruisce più spesso — una schermata lista-più-dettaglio, un flusso con form — e crea l'implementazione di riferimento: layer API tipizzato, error boundary, stati di caricamento, test. Non una pagina di wiki: codice funzionante nel repository, che la gente copia. Un pattern che non è più facile da seguire che da ignorare verrà ignorato.

3. Strangolare seguendo il traffico, non l'estetica

Ora si percorre la mappa della leva. I moduli con più modifiche e più difetti vengono ricostruiti per primi sulla strada asfaltata — uno alla volta, ognuno rilasciato in produzione dietro lo stesso URL. Il codice brutto che nessuno tocca resta brutto. Se l'è guadagnato: funziona e non dà fastidio a nessuno. Il refactoring estetico del codice stabile è il modo in cui muoiono i budget di modernizzazione.

4. Rendere visibile la tendenza

Scegli due o tre numeri che tutto il team può vedere muoversi: copertura dei tipi, dimensione del bundle, difetti per rilascio, tempo di merge. Pubblicali ogni mese. Un team che guarda una linea di tendenza la difende; un team che non la guarda torna indietro nel giro di un trimestre.

Come funziona nella realtà

Su un grande e-commerce di cui ho guidato il front-end abbiamo fatto esattamente questo: standard fatti rispettare in review dalla prima settimana, TypeScript strict come strada asfaltata, e i componenti principali del catalogo — l'area della codebase con più modifiche in assoluto — ricostruiti in modo incrementale mentre il treno dei rilasci continuava a partire ogni settimana. Nessun blocco delle feature, nessun branch monstre, e nel giro di due trimestri il team era più veloce in modo misurabile, e più sereno. La seconda parte conta più di quanto sembri: un team che smette di avere paura del proprio codice prende decisioni migliori su tutto il resto.

I tempi, detti onestamente

Per il front-end di un prodotto di medie dimensioni, il risanamento è una partita che si gioca in trimestri, non in settimane — ma la curva piega presto: l'emorragia si ferma la prima settimana, la strada asfaltata esiste entro un mese, e il primo modulo ad alta leva arriva in produzione poco dopo. Se qualcuno ti promette una codebase trasformata in tre settimane, ti sta descrivendo una demo.

Lavoro come software architect con focus sul front-end: modernizzo prodotti cresciuti più in fretta del loro codice, senza fermarli. Se il tuo front-end è diventato la parte della roadmap che tutti evitano, parliamone: una call conoscitiva di 30 minuti è gratuita e di solito chiarisce molto.