Domande da porre a uno sviluppatore sul codice legacy prima che se ne vadano? [duplicare]

Dipende dal tuo lasso di tempo, dalla documentazione esistente (se presente), dall'intervallo tra i progetti (300 oltre 1 anno o oltre 30 anni), ecc.

Inizia con le app più importanti, quelle che richiedono le modifiche più frequenti e vai indietro. Capisci chi è il migliore che puoi, chiedi al dev. mostra il codice e i frequenti punti di cambiamento.

Se è travolgente vedi se c'è la possibilità di essere d'accordo per lo sviluppo. avere una tariffa oraria fissa che potrebbe essere caricata per assistere dopo che se ne sono andati nel caso in cui ne avessi bisogno.

Chiedi le sue informazioni di contatto. Averli disponibili come risorsa (possibilmente a tariffe di appaltatori, o eventualmente a un pranzo occasionale) è inestimabile per mantenere in funzione i sistemi legacy.

Indipendentemente da quanto sopra, tuttavia, farli mappare il sistema da un livello elevato (compresi i database accessibili e gli account utilizzati). Vuoi anche chiedere "trucchi" nascosti di cui sono a conoscenza; e prendi nota attenta (questi possono risparmiare un lotto di tempo lungo la strada, se sai cosa cercare).

• cheatsheets
• Errori comuni e relative procedure di risoluzione dei problemi, soluzioni alternative
• Elenco prioritario di refactoring in sospeso
• Elenco di errori che non è stato in grado di riprodurre
• Spiegazione delle autorizzazioni e dei ruoli
• Database, informazioni sulle connessioni, account amministrativi e le loro password
• Password per repository di versioni
• Spiegazione dei processi di crontab e dei processi batch
• Informazioni di contatto dei custodi delle attività commerciali (i "proprietari" non IT delle applicazioni commerciali)
• Account utente del sistema operativo e password del proprietario delle attività di crontab / schedule
• Informazioni di contatto di se stesso
• Elenco dei moduli problematici
• Script per correggere o cancellare i dati inseriti male a causa di errori dell'app
• Discussione sulla parte dei modelli di database che non sono ovvi o chiari (un modello ER tracciato sarebbe bello) per ogni database.
• Considerazioni sul tempo di vita dei dati che potrebbero non essere ben documentate, ad esempio: troncare questa tabella temporale ogni N mesi, oppure i dati di questa tabella transazionale devono passare a un database storico ogni N anni, ecc.
• Procedure aziendali, comprese le procedure per il recupero dei nodi del cluster, la promozione di un nodo slave per il master e viceversa, ecc.
• Elenco prioritario di requisiti in sospeso, come modifiche, nuovi report, ecc.
• Interfaccia con altri sistemi o app.
• Dipendenze da API esterne