Recupero di progetti
La tua applicazione non funziona più: cosa verificare prima di ricostruirla?
Accessi, codice, dati, percorsi e deployment: una checklist per decidere cosa riparare o ricostruire, illustrata dal recupero di HODNOS.
La risposta in breve
Un’applicazione bloccata richiede innanzitutto fatti: cosa fallisce, cosa resta accessibile e cosa occorre preservare. Questi riscontri permettono di scegliere tra una riparazione, un recupero mirato e una ricostruzione.
- Recupera gli accessi, il codice e i dati prima di introdurre modifiche nell’applicazione utilizzata.
- Decidi in base ai percorsi e ai vincoli riscontrati: l’età di una tecnologia non basta a giustificare una riscrittura.
- Includi test, passaggio in produzione e consegna nel perimetro di recupero, con criteri di validazione espliciti.
- CapireCodice, accessi e percorsi
- ProteggereBackup e versionamento
- RilanciareFunzioni utili e test
Descrivi cosa non funziona più
Una pagina che si apre non dimostra che l’applicazione funzioni. Un utente può vedere il proprio account senza riuscire a prenotare, pagare o ritrovare una richiesta. Parti dalle azioni di business: chi cerca di fare cosa, in quale momento e con quale risultato? Conserva un esempio riproducibile e il messaggio di errore, se disponibile.
Per un dirigente, questa descrizione permette di ordinare le conseguenze per importanza: richieste perse, lavoro manuale o attività interrotta. Per il team tecnico, fornisce un punto di partenza verificabile. Distingui un guasto recente da una funzione mai diventata operativa. La risposta a una regressione nota può differire dal recupero di un prodotto incompiuto.
Il percorso atteso
Esempio: un cliente sceglie una fascia oraria, conferma la prenotazione e riceve la conferma.
Il punto di rottura
Indica il passaggio esatto, l’account di test utilizzato e il comportamento osservato, senza inviare password nel documento iniziale.
La priorità aziendale
Precisa se esiste una soluzione provvisoria e quali operazioni devono riprendere per prime.
Recuperare ciò che serve per intervenire
La diagnosi dipende dagli elementi accessibili. Il codice distribuito può differire da quello nel repository; un backup può esistere senza che il ripristino sia stato verificato. Occorre riconciliare le fonti, l’applicazione realmente utilizzata e i dati. Questo passaggio evita decisioni basate su una versione incompleta del progetto.
Chiarisci chi controlla ogni servizio e come verranno trasferiti gli accessi. Puoi partire da un inventario senza modificare la produzione. Prima di intervenire, concorda i backup necessari e la procedura da seguire se la modifica non produce il risultato atteso.
- Codice sorgente disponibile, repository Git e versione corrispondente all’applicazione distribuita.
- Hosting, dominio, certificati e procedura di deployment identificati.
- Database, file degli utenti, esportazioni e backup localizzati.
- Servizi di terze parti elencati: pagamenti, email, archiviazione, autenticazione e API.
- Account di test, registri degli errori e documentazione disponibili.
- Responsabili degli accessi e condizioni del passaggio di consegne definiti.
Riparare, recuperare una parte o ricostruire?
Un vecchio codice PHP o un MVP costruito con uno strumento visuale non sono, da soli, un motivo per rifare tutto. La decisione dipende da ciò che resta utilizzabile, dai dati da preservare, dagli usi attesi e dalla capacità di verificare le evoluzioni future. Un cambio di tecnologia deve rispondere a un vincolo identificato.
Una buona proposta spiega cosa conserva, cosa sostituisce e perché. Precisa anche le incertezze che la diagnosi deve risolvere. Se il problema è ancora poco compreso, impegnarsi subito in un rifacimento completo rende difficile confrontare il costo della riparazione con quello della ricostruzione.
| Riscontro da confermare | Opzione da valutare | Verifica attesa |
|---|---|---|
| Una modifica recente ha rotto un percorso prima affidabile | Correzione mirata o ritorno a una versione nota | Riprodurre il guasto e verificare il percorso dopo la correzione. |
| Alcuni moduli funzionano e restano accessibili | Recupero progressivo delle parti difettose | Testare gli scambi tra gli elementi conservati e sostituiti. |
| Il prodotto funziona, ma il deployment resta manuale e fragile | Maggiore affidabilità del deployment e della gestione operativa | Distribuire una versione identificata e preparare un ripristino. |
| I percorsi essenziali non sono utilizzabili e si può recuperare pochissimo codice | Ricostruzione del perimetro prioritario | Motivare gli elementi conservati e validare i dati migrati. |
HODNOS: rimettere in funzione una piattaforma dopo diversi tentativi
HODNOS mette in contatto clienti e artisti. Al momento del recupero, i percorsi essenziali di prenotazione, pagamento e messaggistica non erano più realmente utilizzabili. L’applicazione si basava su vecchio codice PHP, modificato direttamente via FTP su un server OVH, senza versionamento su GitHub. Diversi sviluppatori erano intervenuti senza riuscire a rimetterla in funzione.
CUB3 ha recuperato il codice, creato il repository Git e identificato i pochi elementi utili alla migrazione. L’incarico ha poi riguardato la ricostruzione di quasi tutta la piattaforma: registrazione, prenotazione, pagamento, messaggistica e back-office. L’infrastruttura è stata trasferita su AWS e descritta con Terraform. Web, iOS e Android sono stati consegnati in tre mesi, con tre membri di CUB3 coinvolti.
Questo risultato riguarda il ripristino del funzionamento e una consegna tecnica. Non dimostra un risultato commerciale, e tre mesi non sono un termine universale di recupero. La lezione utile è il metodo: recuperare, stabilire i fatti, scegliere gli elementi da ricostruire e poi verificare i percorsi essenziali.
Definisci cosa significa «di nuovo funzionante»
Un recupero deve portare a criteri che puoi controllare. Sostituire una schermata con una dimostrazione completa del percorso permette di verificare i passaggi, i permessi e i dati. Chiarisci anche i casi di errore: pagamento rifiutato, dato mancante o account non autorizzato, secondo il tuo prodotto.
La pubblicazione online fa parte del lavoro da preparare. Concorda le condizioni del passaggio, le possibili interruzioni, la verifica dei dati e chi è autorizzato a decidere. Il seguito dopo la consegna deve essere esplicito: chi riceve una segnalazione, come viene valutata e quale assistenza è stata concordata.
- I percorsi concordati sono dimostrati con i profili interessati.
- I dati recuperati sono controllati secondo criteri concordati.
- La versione consegnata e le condizioni di deployment sono identificabili.
- Il passaggio, le verifiche e il ripristino sono preparati.
- Vengono trasferiti gli accessi, la documentazione e il supporto dopo la consegna.
Sul campo
Un progetto concreto
Vecchio PHP, modifiche via FTP e assenza di versionamento su GitHub: una piattaforma rimessa in funzione, con web, iOS e Android consegnati in tre mesi.
Il recupero di HODNOS