Ereditare un codice disordinato: come salvare un progetto bloccato
Uno sviluppatore è sparito, o lo sviluppo si è arenato, e ora ti ritrovi davanti a un codice che nessuno capisce. Ecco come prendo in mano in sicurezza i progetti disordinati, e come decidere se sistemare o ricostruire.
Shayan Jamil·20 maggio 2026·6 min di lettura
Una quota sorprendente del mio lavoro inizia sempre allo stesso modo: un founder ha un prodotto costruito a metà, lo sviluppatore originale se n'è andato o non risponde più, e nessuno è in grado di spiegare come funziona. Il progetto è fermo, il budget già speso sembra a rischio e la domanda è semplice ma angosciante: si può salvare, o ricominciamo da capo?
Ne ho presi in mano parecchi, e la situazione non è quasi mai disperata come sembra sul momento. Però va gestita con attenzione. Buttarsi a capofitto e cambiare le cose alla cieca è il modo in cui un salvataggio si trasforma in un secondo disastro. Ecco come lo affronto.
Il problema di business: sei bloccato e il tassametro corre
Un progetto fermo fa male in un modo particolare. Hai già investito soldi e tempo, non riesci ad andare avanti e non sei nemmeno sicuro di cosa hai in mano. Ogni opzione sembra rischiosa: se continui potresti costruire sulla sabbia; se ricominci potresti buttare via lavoro che in realtà andava bene.
La mossa peggiore è farsi prendere dal panico: abbandonare tutto d'istinto, oppure affidarsi a qualcuno che inizia subito a riscrivere senza capire cosa c'è. Entrambe le strade sprecano soldi. Il primo passo giusto è sempre lo stesso: capire prima di toccare.
Primo passo: valutare prima di cambiare qualsiasi cosa
Prima di modificare una sola riga, voglio un quadro chiaro di ciò che esiste. Questo significa leggere il codice, avviare l'app e capire:
- Cosa funziona davvero e cosa invece è rotto o lasciato a metà.
- Come è costruito: la struttura, il modello dei dati, le decisioni principali.
- Cosa è pericoloso: backup mancanti, falle di sicurezza, nessun modo sicuro per fare il deploy.
- Cosa è obsoleto: i progetti fermi sono spesso bloccati su una versione di runtime o framework che non riceve più aggiornamenti di sicurezza. Node.js 20, ad esempio, una scelta comune un paio di anni fa, ha raggiunto il fine vita ad aprile 2026. Saperlo subito ti dice se gli aggiornamenti devono far parte del piano.
- Cosa è recuperabile e cosa è davvero irrecuperabile.
Questa valutazione è la parte più preziosa di un salvataggio. Trasforma "non abbiamo idea di cosa abbiamo" in una mappa chiara e onesta, da cui dipende ogni buona decisione successiva.
La prima cosa che controllo in ogni salvataggio
Il progetto può essere avviato, salvato con un backup e distribuito in sicurezza, senza rischiare di perdere dati o rompere ciò che funziona? Prima di migliorare qualsiasi cosa, mi assicuro che ci sia una rete di sicurezza. Non si opera senza prima essere in grado di fermare l'emorragia.
Sistemare o ricostruire? Come decido
È la domanda a cui i founder vogliono più di tutto una risposta, e la risposta onesta è "dipende dalle fondamenta". Ecco la logica di massima:
Propendo per sistemare quando la struttura di base è solida, il modello dei dati ha senso, l'architettura è ragionevole e i problemi sono disordine e pezzi mancanti più che difetti di fondo. La maggior parte dei progetti fermi è in questa situazione. Non hanno bisogno di essere riscritti; hanno bisogno di qualcuno che li capisca, li stabilizzi e porti a termine il lavoro.
Propendo per ricostruire quando le fondamenta sono davvero compromesse: un modello dei dati che non può sostenere il prodotto, o un'architettura che rende pericolosa ogni modifica. Anche in quel caso, raramente si tratta di "buttare via tutto". Di solito si ricostruisce il nucleo difettoso mantenendo le parti che funzionano.
Riscrivere da zero sembra pulito e allettante, ma butta via ogni lezione che il codice esistente ha già imparato. Considero una ricostruzione completa l'ultima risorsa, non la scelta predefinita, perché il più delle volte il progetto si può salvare spendendo molto meno che ricominciando. (Impostare bene quelle fondamenta è anche ciò che definire bene il perimetro di un MVP serve a garantire fin dall'inizio.)
Perché un subentro attento è importante
Un salvataggio fatto di fretta tende a creare nuovi problemi mentre risolve quelli vecchi. Uno fatto con attenzione fa l'opposto: stabilizza ciò che è fragile, documenta ciò che era un mistero e porta il progetto a un punto in cui il lavoro può procedere in sicurezza. Quella documentazione conta più di quanto i founder si aspettino: spesso il progetto si è fermato proprio perché tutto viveva nella testa di una sola persona. Metterlo per iscritto significa non essere mai più così esposti. Anche deployment e ambienti affidabili fanno di solito parte della soluzione, perché i progetti fermi spesso non hanno un modo sicuro per rilasciare modifiche.
Un esempio concreto
Gran parte del mio lavoro ha riguardato il subentro nel codice di altri e la sua prosecuzione: completare funzionalità, stabilizzare ciò che era traballante e portare i prodotti a un punto in cui potessero davvero essere rilasciati e crescere. La forma del lavoro è sempre la stessa: prima capire, poi rendere sicure le modifiche, sistemare o ricostruire le parti giuste in base alle fondamenta e documentare strada facendo, così che la persona successiva (o il founder) non debba tirare a indovinare. Il sollievo del founder, di solito, deriva meno da un codice brillante e più dall'avere finalmente chiarezza su ciò che ha in mano e un percorso realistico per andare avanti.
Errori comuni nel salvataggio di un progetto
- Lanciarsi in preda al panico in una riscrittura completa prima di capire cosa c'è davvero.
- Cambiare le cose prima di avere un modo sicuro per fare backup e deploy.
- Dare per scontato che sia tutto da buttare solo perché una parte lo è.
- Affidarsi a qualcuno che non vuole leggere il codice esistente e vuole solo ripartire da zero.
- Non documentare ciò che si impara, così il progetto resta a una sola persona di distanza dal bloccarsi di nuovo.
- Curare i sintomi invece dei problemi di fondo che hanno causato il disordine.
Come affronto un salvataggio
- Prima valuto: leggo il codice, lo avvio e mappo cosa funziona e cosa è pericoloso.
- Metto in piedi una rete di sicurezza: backup e un modo sicuro per fare il deploy prima di cambiare qualsiasi cosa.
- Ti do un verdetto onesto: sistemare, ricostruire in parte o ricostruire del tutto, con le relative motivazioni.
- Stabilizzo i rischi urgenti prima di aggiungere qualcosa di nuovo.
- Documento strada facendo, così il progetto non sarà mai più una scatola nera.
- Lo faccio ripartire verso il lancio o il traguardo su cui eri bloccato.
L'obiettivo è sbloccarti con il minimo spreco: salvare ciò che vale la pena salvare, sostituire solo ciò che lo richiede davvero e restituirti un progetto di cui fidarti.
Sei bloccato con un progetto fermo?
Se hai un prodotto costruito a metà e uno sviluppatore che non si fa più sentire, o un codice che nessuno sa spiegare, posso valutarlo con onestà, dirti se conviene sistemarlo o ricostruirlo e poi rimetterlo in moto.
Leggi come lavoro, guarda cosa ho realizzato e contattami raccontandomi a che punto sei. Troviamo insieme la strada realistica per andare avanti.