Suggerimenti per sviluppare ulteriormente su un sistema legacy? [chiuso]

Inizia a scrivere test per il codice ora, prima di apportare modifiche. Questo ti dà una linea di base della funzionalità corrente. Avrai abbastanza tempo per capire come aggiungere nuove funzionalità, non vorrai passare il tempo a capire come hai rotto qualcosa. E questo è se scopri che l'hai rotto.

Il test automatico ti darà una certa parvenza di confidenza con lo stato attuale delle cose. Potrebbe anche indicare alcune cose che non funzionano come previsto ora. Ma soprattutto, ti dirà immediatamente quando hai fatto qualcosa che rompe qualcos'altro. Se un test fallisce dopo aver controllato una modifica, saprai dove hai cambiato le cose e dove cercare i problemi.

Oltre a ciò, ottieni il maggior numero di informazioni storiche possibili. Se l'ultima persona che possedeva il codice è ancora lì, ottenere quante più informazioni possibile dalla propria testa. Speriamo che il codice sia commentato e che ci sia documentazione.

Dovresti leggere il seguente libro:

link

Ho sentito Michael partecipare a una conferenza e ho comprato il suo libro per tutta la mia squadra. Si riduce a test di scrittura, ma non i tuoi test normali. Scrivi test che passano indipendentemente dal fatto che siano giusti o meno. Quello che stai cercando di fare è creare una verifica che non abbia infranto alcuna funzionalità esistente se quella funzionalità è giusta o meno è una decisione per il responsabile del supporto.

Nel libro entra nei dettagli su come modificare il codice esistente in modo che sia testabile. Creazione di mock, ecc. Può essere un processo lungo, ma dopo aver eseguito una serie di test che verifica la funzionalità esistente, è possibile iniziare a rifattorizzare il codice peggiore.

Sono stato in grado di migliorare un prodotto esistente che era un gran casino come questo. Controllore preparato in casa che era più Model-View di MVC. Alla fine abbiamo avuto un prodotto molto più stabile ed è stato in grado di migliorare davvero l'affidabilità del sistema.

Ci sono alcune pratiche consigliate a seconda della forma approssimativa della palla di cerotti e degli obiettivi del sistema.

Se c'è un database dietro tutto ciò, abbiamo avuto un certo successo nel mantenere i sistemi esistenti in esecuzione in ogni situazione e fare il follwoing.

Piccoli ritocchi o correzioni. Risolto il problema attuale.

Nuovi sottosistemi .

Con l'arrivo di una nuova scala più grande (singoli processi o sottosistemi) puoi usare questi come scusa per iniziare la migrazione del sistema verso un mondo migliore.

Crea un nuovo database e una vista memorizzata / livello di memorizzazione memorizzato per trasformare la visualizzazione OLD del mondo nella nuova vista del mondo (che quindi si programma contro) e un BUS per tornare indietro. Se si utilizza il BUS per descrivere l'intento degli utenti piuttosto che il cambiamento dei dati, di solito si può capire come trasferire i dati all'indietro abbastanza facilmente.

Questo ti permette di costruire i nuovi sottosistemi nella tua nuova e brillante piattaforma di scelta. Se il suo web / silverlight qualunque cosa tu possa, nella maggior parte dei casi fornisci "punti di avvio" dal vecchio sistema che fa qualcosa di simile

ShellExecute ("NewApp; ParametersToDirectAppToNewFunction") o apri nel browser l'URL corretto (stesso concetto di tecnologia diversa).

Il vecchio database rimane la "singola fonte di verità" ancora per un po 'e si traducono automaticamente i dati "Inoltra" nel nuovo sistema su trigger o pull da in quando si popola il nuovo sistema (tramite un livello API in SQL o nel codice).

Alla fine puoi consumare sempre più sistemi finché il vecchio sistema non lo fa più e puoi disattivare il vecchio database e il sistema precedente.

NB. Tutti i tuoi rapporti dovrebbero essere fatti fuori dal nuovo livello API e non andare mai direttamente.

Questo approccio richiede una buona conoscenza sia di Business Domain che di modellazione SQL / Data in anticipo e devi essere abbastanza bravo a ottimizzare le prestazioni per renderlo fattibile ... se sei bravo con tutto questo, questo funziona abbastanza bene.

Se hai qualche parola sul programma di sviluppo che preleva le prime schermate "satellite" e poi "meno core" per rimodellarle e sostituirle, diciamo che 1 su 3 "sprint di sviluppo" ti aiuterà a cancellare l'arretrato dell'eredità e a dare tu "Clienti" la possibilità di rivisitare e migliorare i processi.