Recuperació de projectes
La vostra aplicació ja no funciona: què cal comprovar abans de reconstruir-la?
Accessos, codi, dades, recorreguts i desplegament: una llista per decidir què cal reparar o reconstruir, il·lustrada per la recuperació de HODNOS.
La resposta breu
Una aplicació bloquejada exigeix primer fets: què falla, què continua sent accessible i què cal preservar. Aquestes constatacions permeten triar entre una reparació, una recuperació específica i una reconstrucció.
- Recupereu els accessos, el codi i les dades abans d’introduir canvis a l’aplicació utilitzada.
- Decidiu a partir dels recorreguts i les limitacions constatades: l’antiguitat d’una tecnologia no basta per justificar una reescriptura.
- Incloeu proves, transició i traspàs a l’abast de recuperació, amb criteris de validació explícits.
- EntendreCodi, accessos i recorreguts
- ProtegirCòpies i control de versions
- RellançarFuncions útils i proves
Descriviu el que ja no funciona
Que una pàgina es mostri no demostra que l’aplicació funcioni. Un usuari pot veure el seu compte sense poder reservar, pagar o recuperar una petició. Comenceu per les accions de negoci: qui intenta fer què, en quin moment i amb quin resultat? Conserveu un exemple reproduïble i el missatge d’error, si el teniu.
Per a un directiu, aquesta descripció permet jerarquitzar les conseqüències: peticions perdudes, treball manual o activitat interrompuda. Per a l’equip tècnic, ofereix un punt de partida verificable. Distingiu una avaria recent d’una funció que mai no ha estat operativa. La resposta a una regressió coneguda pot diferir de la recuperació d’un producte inacabat.
El recorregut esperat
Exemple: un client tria una franja horària, confirma la reserva i rep la confirmació.
El punt de fallada
Indiqueu el pas exacte, el compte de prova utilitzat i el comportament observat, sense transmetre cap contrasenya al document inicial.
La prioritat de negoci
Preciseu si hi ha una alternativa provisional i quines operacions s’han de reprendre primer.
Recuperar el que cal per intervenir
El diagnòstic depèn dels elements accessibles. El codi desplegat pot diferir del repositori; pot existir una còpia de seguretat sense que s’hagi verificat la restauració. Cal conciliar les fonts, l’aplicació realment utilitzada i les dades. Aquest pas evita decidir sobre una versió incompleta del projecte.
Preciseu qui controla cada servei i com es transmetran els accessos. Podeu començar per un inventari sense modificar la producció. Abans d’intervenir, acordeu les còpies de seguretat necessàries i el procediment que cal seguir si el canvi no dona el resultat esperat.
- Codi font disponible, repositori Git i versió corresponent a l’aplicació desplegada.
- Allotjament, domini, certificats i procediment de desplegament identificats.
- Base de dades, fitxers d’usuaris, exportacions i còpies de seguretat localitzats.
- Serveis de tercers enumerats: pagaments, correus, emmagatzematge, autenticació i API.
- Comptes de prova, registres d’errors i documentació disponibles.
- Responsables dels accessos i condicions de traspàs definits.
Reparar, recuperar-ne una part o reconstruir?
Un codi PHP antic o un MVP construït amb una eina visual no són, per si sols, motius per refer-ho tot. La decisió depèn del que continua sent aprofitable, de les dades que cal preservar, dels usos esperats i de la capacitat de verificar les evolucions següents. Un canvi de tecnologia ha de respondre a una limitació identificada.
Una bona proposta explica què conserva, què substitueix i per què. També precisa les incerteses que ha de resoldre el diagnòstic. Si el problema encara s’entén malament, comprometre’s immediatament amb una reforma completa dificulta comparar el cost de reparar amb el de reconstruir.
| Constatació per confirmar | Opció que cal considerar | Verificació esperada |
|---|---|---|
| Un canvi recent ha trencat un recorregut abans fiable | Correcció específica o retorn a una versió coneguda | Reproduir la fallada i verificar el recorregut després de la correcció. |
| Alguns mòduls funcionen i continuen sent accessibles | Recuperació progressiva de les parts defectuoses | Provar els intercanvis entre els elements conservats i substituïts. |
| El producte funciona, però el desplegament continua sent manual i fràgil | Més fiabilitat del desplegament i l’explotació | Desplegar una versió identificada i preparar un retorn enrere. |
| Els recorreguts essencials no són utilitzables i es pot recuperar molt poc codi | Reconstrucció de l’abast prioritari | Justificar els elements conservats i validar les dades migrades. |
HODNOS: tornar a posar en marxa una plataforma després de diversos intents
HODNOS connecta clients amb artistes. En assumir el projecte, els recorreguts essencials de reserva, pagament i missatgeria ja no eren realment utilitzables. L’aplicació es basava en codi PHP antic, modificat directament per FTP en un servidor OVH, sense control de versions a GitHub. Diversos desenvolupadors hi havien intervingut sense aconseguir tornar-la a posar en funcionament.
CUB3 va recuperar el codi, va crear el repositori Git i va identificar els pocs elements útils per a la migració. La missió va passar després a reconstruir gairebé tota la plataforma: registre, reserves, pagaments, missatgeria i back-office. La infraestructura es va traslladar a AWS i es va descriure amb Terraform. Web, iOS i Android es van lliurar en tres mesos, amb tres membres de CUB3 mobilitzats.
Aquest resultat correspon a la recuperació del funcionament i a un lliurament tècnic. No demostra un resultat comercial, i tres mesos no és un termini universal de recuperació. La lliçó útil és el mètode: recuperar, establir els fets, triar els elements que cal reconstruir i després verificar els recorreguts essencials.
Definiu què vol dir «de nou en funcionament»
Una recuperació ha de conduir a criteris que pugueu comprovar. Substituir una captura per una demostració completa del recorregut permet verificar els passos, els permisos i les dades. Preciseu també els casos de fallada: pagament rebutjat, dada absent o compte no autoritzat, segons el vostre producte.
La posada en línia forma part del treball que cal preparar. Acordeu les condicions de transició, les possibles interrupcions, la verificació de les dades i qui està autoritzat per decidir. El seguiment després del lliurament ha de ser explícit: qui rep una incidència, com s’avalua i quin acompanyament s’ha acordat.
- Els recorreguts acordats es demostren amb els perfils corresponents.
- Les dades recuperades es comproven segons criteris acordats.
- La versió lliurada i les condicions de desplegament són identificables.
- La transició, les verificacions i el retorn enrere estan preparats.
- Es transmeten els accessos, la documentació i el seguiment després del lliurament.
Sobre el terreny
Un projecte concret
PHP antic, modificacions per FTP i absència de control de versions a GitHub: una plataforma recuperada, amb web, iOS i Android lliurats en tres mesos.
La recuperació de HODNOS