Riscrivere da zero e quasi sempre la scelta sbagliata
La tentazione di buttare via tutto e ripartire da zero e forte quando ci si trova davanti a un applicazione PHP legacy vecchia di anni, con codice misto, nessun test e una struttura che nessuno ricorda perche e fatta cosi. Ma la riscrittura completa e rischiosa: si perde la conoscenza di business accumulata nel codice, si sottostimano i tempi e si resta senza prodotto funzionante per mesi — a volte anni.
Joel Spolsky lo scrisse nel 2000 e vale ancora oggi: la riscrittura da zero e il peggior errore strategico che un team di sviluppo possa fare. Il vecchio codice, per quanto brutto, funziona. Contiene anni di bug fix, edge case gestiti e regole di business che nessun documento ha mai catturato. Buttarlo via significa perdere tutto questo e sperare di riscriverlo correttamente al primo tentativo — cosa che non succede mai.
L alternativa e il refactoring incrementale: migliorare il sistema un pezzo alla volta, senza mai interrompere il funzionamento. E meno spettacolare, ma funziona. E soprattutto, produce valore dal giorno uno — non dopo sei mesi di riscrittura senza niente da mostrare.
Strategia pratica di modernizzazione
Il primo passo non e toccare il codice: e capire cosa fa. Mappare i flussi critici, identificare le parti piu fragili, aggiungere test sulle funzioni che non possono rompersi. Solo dopo si inizia a isolare, semplificare e aggiornare. Questo approccio richiede disciplina, ma e l unico che funziona in modo affidabile su sistemi in produzione.
Fase 1: Stabilizzare e proteggere
Prima di qualsiasi modifica, serve una rete di sicurezza. Questo significa aggiungere test automatici sui percorsi critici dell applicazione. Non serve una copertura del 100% — serve testare le funzioni che, se si rompono, fermano il business. Autenticazione, flussi di pagamento, generazione documenti, importazione dati: parti da li.
In parallelo, configura un sistema di version control se non c e gia (incredibilmente, molte applicazioni legacy non usano git), e un ambiente di staging che replica la produzione. Ogni modifica deve essere testabile in un ambiente sicuro prima di andare live.
Fase 2: Isolare e separare
Il problema piu comune del codice legacy e l accoppiamento: la logica di business e mischiata con la presentazione, le query SQL sono sparse ovunque, la configurazione e codificata in costanti globali. Il lavoro di questa fase e separare le responsabilita senza cambiare il comportamento.
Tecniche concrete che funzionano:
- Introdurre autoloading e namespacing dove manca — eliminare i require manuali e il primo passo verso una struttura moderna
- Estrarre la logica di business in classi dedicate — separare il "cosa fa" dal "come lo mostra"
- Sostituire query inline con un layer di accesso dati strutturato — centralizzare le query rende il codice piu sicuro e testabile
- Migrare la configurazione da costanti sparse a un sistema centralizzato — un unico punto dove cambiare ambiente
- Isolare le dipendenze esterne dietro interfacce — se domani cambi il gateway di pagamento, cambi una classe, non cento file
Fase 3: Aggiornare e modernizzare
Con i test in posizione e il codice separato in moduli, si puo iniziare ad aggiornare. Aggiornare la versione di PHP e spesso il primo passo piu impattante: ogni versione maggiore porta miglioramenti di performance significativi (PHP 8.x e mediamente 2-3 volte piu veloce di PHP 5.6), oltre a funzionalita del linguaggio che rendono il codice piu leggibile e sicuro.
L aggiornamento di PHP va fatto gradualmente: prima risolvere tutti i deprecation warning della versione attuale, poi salire di una versione alla volta. Ogni step viene testato e validato prima di procedere al successivo. Saltare versioni e possibile ma rischioso — meglio un percorso piu lungo ma controllato.
Errori comuni da evitare
In anni di lavoro su codice legacy, ho visto gli stessi errori ripetersi:
- Riscrivere tutto insieme: il refactoring incrementale funziona perche ogni passo e piccolo e reversibile. Cambiare tutto in un colpo e una riscrittura mascherata
- Non aggiungere test prima di modificare: senza test stai giocando alla roulette russa con il codice in produzione
- Inseguire la perfezione: l obiettivo non e il codice perfetto, e il codice migliore di prima. Il meglio e nemico del bene
- Sottovalutare la documentazione: ogni scoperta sul comportamento del sistema legacy va documentata. Tra sei mesi non ricorderai perche quella funzione ha quel workaround
- Non coinvolgere chi usa il sistema: gli utenti conoscono edge case che non sono documentati da nessuna parte
Risultati concreti
Ogni intervento migliora la situazione senza fermare il business. Dopo qualche mese di lavoro costante, l applicazione e irriconoscibile — e non ha mai smesso di funzionare. Ho visto applicazioni PHP legacy passare da incubi di manutenzione a sistemi moderni, testati e piacevoli da sviluppare, in 6-12 mesi di lavoro incrementale.
I benefici si vedono da subito: meno bug in produzione, deploy piu frequenti e sicuri, sviluppo di nuove feature piu veloce, onboarding di nuovi sviluppatori piu semplice. E il ROI del refactoring incrementale e misurabile: meno ore spese a correggere bug, meno downtime, piu capacita di evolvere il prodotto.
Il refactoring di codice legacy non e il lavoro piu glamour nel mondo dello sviluppo software, ma e uno dei piu importanti. E quando fatto bene, e anche uno dei piu soddisfacenti.