Ci sono tre modi per ereditare una codebase: la sua azienda ne ha acquisita una, ha assunto la guida tecnica, oppure l'agenzia che l'ha sviluppata non è più disponibile. In tutti e tre i casi riceve un sistema, una serie di aspettative e circa un mese prima che qualcuno in posizione senior chieda un parere.
La tentazione è iniziare leggendo il codice. Non lo faccia. La qualità del codice è uno degli elementi meno predittivi che può valutare nella prima settimana, ed è il più facile su cui farsi un'opinione ingiusta. Questo è l’ordine che seguiamo.
Una regola prima di iniziare: nella prima settimana non cambi nulla. Né una dipendenza, né un valore di configurazione, né un composer update. Non può ancora sapere cosa sia essenziale al funzionamento, e un’interruzione causata da Lei compromette la credibilità nel segnalare quelle che non ha causato.
Settimana 1: Si Riesce a Farlo Girare?
Tutto il resto è ipotesi finché il sistema non gira su una macchina sotto il Suo controllo.
- Faccia funzionare un ambiente locale partendo da una copia pulita e misuri quanto tempo serve. Questo dato è il miglior indicatore di quanto costerà ogni modifica futura. Due ore sono un buon segnale; due settimane dicono già quasi tutto quello che serve sapere.
- Faccia l’inventario degli ambienti. Produzione, staging e quei due server che nessuno ha menzionato. Li trovi leggendo DNS e account cloud, non chiedendo.
- Verifichi cosa gira dove — web server, worker, cron, code di lavoro, report schedulati, webhook receiver. Il cron job non documentato è il classico rischio nascosto.
- Verifichi di avere tutti gli account. Registrar del dominio, DNS, hosting, cloud, repository, CI, error tracking, gateway di pagamento, invio email. L’accesso mancante è un problema commerciale da segnalare subito, non tra quattro settimane.
- Verifichi che i backup esistano e siano ripristinabili. Backup non testati sono solo una voce. Ripristini uno in un ambiente di test e lo esamini.
- Scopra chi ha le conoscenze. Spesso è una sola persona, a volte in un’azienda che non la impiega più. È la risorsa più a rischio — prenda appuntamento subito.
Settimana 2: Rischio, non Qualità
Ora misuri l’esposizione. Sono queste le evidenze che cambiano le decisioni e fanno approvare i budget.
- Versione di PHP, per ogni ambiente, rispetto alla timeline di supporto ufficiale. Una versione non supportata è la criticità che supera tutte le altre in questa lista.
- Età delle dipendenze e stato delle vulnerabilità. Esegua un audit sul file di lock. Conti di quante major versioni è indietro il framework — è questo dato, non lo stile del codice, a indicare il costo di un aggiornamento.
- Dipendenze abbandonate. Pacchetti senza release da anni, o fork che puntano a repository personali. Ognuno è un progetto che ha ereditato senza saperlo.
- Segreti nel repository. Esamini tutta la cronologia, non solo lo stato attuale. Consideri compromesso tutto ciò che trova.
- Come sono protetti i dati. Dove risiedono i dati personali, chi può leggerli, cosa è cifrato e quali sono gli obblighi relativi.
- Se il deployment è ripetibile. Un sistema che viene pubblicato modificando file direttamente sul server non consente rollback affidabili, e questo incide su tutte le valutazioni di rischio successive.
Scriva le evidenze come rischi, indicando probabilità, impatto e costo di risoluzione — mai come lamentele sulla squadra precedente. Il destinatario di questo documento è commerciale, e questo codice è scritto male non è un’azione concreta, mentre siamo a 14 mesi da una vulnerabilità non risolta lo è.
Settimana 3: Ora Legga il Codice
Una volta chiarito il contesto, l’analisi del codice diventa utile invece che giudicante. Cerchi struttura e testabilità, non lo stile.
- Esegua un’analisi statica a basso livello e registri il valore di partenza. Non deve correggere, ma misurare. Conta la tendenza nell’anno successivo.
- Verifichi la copertura dei test dove conta — checkout, pagamento, prezzi, tutto ciò che riguarda il denaro. La percentuale complessiva è un dato poco utile; la copertura dei percorsi critici è quella che conta davvero.
- Individui la business logic. In un codice sano si trova in punti riconoscibili. In uno problematico è sparsa tra controller, template e stored procedure dimenticate.
- Cerchi i god object — la classe toccata da ogni funzionalità. Indica dove le modifiche costano di più e dove arriverà il prossimo incidente.
- Legga la cronologia git per individuare il churn. I file modificati più spesso sono dove si svolge davvero il business, e dove l’investimento rende più rapidamente.
- Identifichi ciò che è intoccabile. Ogni sistema legacy ha un modulo che nessuno vuole modificare. Scopra quale sia e perché.
Il bus factor merita una nota a parte. Se una sola persona sa spiegare il flusso degli ordini e nessun altro può farlo, il rischio è superiore a qualsiasi code smell, e la mitigazione — affiancamento, documentazione, una seconda persona che lo conosca davvero — deve iniziare subito, non dopo la valutazione.
Settimana 4: Valutazione e Raccomandazione
Valuti ogni dimensione da 1 (sano) a 5 (critico), e lasci che sia il totale a guidare la raccomandazione, non l’istinto.
- Sicurezza e aggiornamento delle versioni — l’unica dimensione che può imporre una decisione da sola
- Salute delle dipendenze — quanto è arretrato, quanto è abbandonato
- Operabilità — può effettuare deployment, rollback, monitoraggio e ripristino?
- Testabilità — può modificare la logica dei prezzi e sapere se ha rotto qualcosa?
- Comprensibilità — quanto tempo serve perché un nuovo sviluppatore sia produttivo?
- Aderenza al business — risponde ancora alle esigenze aziendali o ostacola la roadmap?
Poi assegni la categoria:
- Prevalenza di 1–2: mantenere e migliorare. Il sistema va bene. Risolva le criticità individuate e prosegua con la roadmap.
- Prevalenza di 2–3: investire in modo mirato. Un programma di remediation finanziato — upgrade di versione, gestione delle dipendenze, test sui percorsi critici — in parallelo alla delivery ordinaria.
- Prevalenza di 3–4: sostituzione incrementale. Strangler fig, sostituendo il sistema rotta per rotta mentre continua a funzionare. Descriviamo questo pattern in dettaglio in migrazione di un monolite PHP legacy a Laravel.
- Prevalenza di 4–5, o aderenza al business pari a 5: ricostruire. Evento raro, e dovrebbe sembrare inevitabile, non attraente. Una ricostruzione motivata solo dalla qualità del codice è spesso una scelta che si rimpiange.
Diffidi del proprio istinto di ricostruire. Quasi ogni sviluppatore che eredita una codebase sconosciuta lo desidera. Quasi nessuno dei progetti che ne derivano rispetta tempi e promesse. Pretenda che sia il punteggio a giustificarlo.
Cosa Consegnare
Il risultato è un unico documento, leggibile anche da chi non è tecnico, che contiene:
- Un riassunto di una pagina con la raccomandazione e tre motivazioni a supporto
- Un registro dei rischi — ogni rilievo con probabilità, impatto e costo di risoluzione, ordinato per urgenza
- La versione e la situazione delle dipendenze, con le date di fine supporto
- Un piano a 90 giorni per le attività che non possono attendere, con stima dei costi
- Le lacune di accesso e proprietà, che di solito sono di natura commerciale più che tecnica
- Una dichiarazione trasparente su ciò che non è stato possibile valutare e su cosa servirebbe per farlo
Questo ultimo punto distingue una valutazione professionale da una semplicemente sicura di sé. Un mese non basta per conoscere ogni dettaglio, e dichiararlo è più credibile che fingere il contrario.
Eseguiamo questa valutazione per i clienti tramite la nostra pratica PHP personalizzata e il nostro team di sviluppo PHP — spesso prima della chiusura di un'acquisizione, talvolta dopo la fine di un rapporto con un'agenzia. Il tema correlato, ovvero se il linguaggio sia il vero problema, è trattato in is PHP still the right choice for eCommerce.
Domande frequenti
Quanto tempo dovrebbe richiedere una valutazione di codice legacy?
Quattro settimane di lavoro part-time sono sufficienti per fornire una raccomandazione solida nella maggior parte dei sistemi di media dimensione. Meno di due settimane producono un'opinione, non una valutazione; più di sei di solito indica che si sta cercando di risolvere i problemi invece di misurarli.
Qual è la prima cosa da verificare?
Se è possibile eseguire il sistema in locale partendo da un checkout pulito e quanto tempo richiede. Questo singolo dato prevede il costo di ogni modifica futura meglio di qualsiasi metrica sulla qualità del codice, ed è disponibile dal primo giorno.
Conviene ricostruire o rifattorizzare un sistema PHP ereditato?
Nella quasi totalità dei casi, conviene rifattorizzare o sostituire in modo incrementale. Ricostruire solo quando il sistema non risponde più alle esigenze aziendali, non quando il codice è poco gradevole. Una ricostruzione motivata solo dalla qualità del codice è quasi sempre fonte di rimpianti.
Qual è il rischio maggiore in una codebase ereditata?
Di solito non è il codice. I rischi maggiori sono una versione PHP non supportata, l’assenza di accesso a un dominio o a un account cloud, backup mai testati, oppure una sola persona che conosce un sottosistema critico. Sono questi i fattori che cambiano le decisioni.
Come presentare i risultati agli stakeholder non tecnici?
Come registro dei rischi: ogni voce con probabilità, impatto sul business e costo di risoluzione, ordinate per urgenza. Mai come critica al team precedente — verrebbe percepita come presa di posizione e renderebbe l’intero documento più facile da ignorare.
Richieda un Secondo Parere
Se ha ereditato un progetto e necessita di un parere indipendente prima di impegnare un budget, eseguiamo la valutazione e le consegniamo il documento. Contatti il nostro team; rispondiamo entro un giorno lavorativo.