Come si fa a continuare a sviluppare grandi (a lungo termine) sistemi software con legacy e il nuovo codice? [chiuso]

Question

Io lavoro su una grande base di codice con una grande base installata di utenti. Il codice è stato originariamente scritto in VB6 con alcuni moduli C ++ COM per il lavoro di basso livello.

E 'del tutto irrealizzabile di riscrivere tutto il codice che è già scritto in VB6 e viene utilizzato dai nostri clienti ogni giorno, ma stiamo anche continuando a migliorare e personalizzazioni del software (grandi e piccole).

La mia soluzione finora è quello di scrivere la maggior parte del nuovo codice in C # (WinForms e WPF anche ora) e quindi utilizzare interoperabilità COM per chiamare i moduli da VB6.

Qualcuno là fuori ha esperienza con suite di software a lungo termine di questo tipo (10 anni) che non possono essere fermati per una riscrittura completa, ma hanno bisogno di un continuo sviluppo nuovo allo stesso tempo. Inoltre, nei sistemi misti come questo, qual è il modo migliore per interfacciare i moduli? Sto usando COM in questo momento, ma ho considerato IPC con processi separati pure.

Answer 1

E 'difficile dare una sola risposta che comprende tutto, ma l'approccio di alto livello è chiaro. Almeno, questo è l'approccio che ho usato. Dare priorità i vostri obiettivi e poi cercare di individuare i costi per raggiungere tali obiettivi. I suoi costi saranno essenzialmente riducono a 'tempo per gli sviluppatori'.

In primo luogo, si vuole tutto ciò che è al lavoro per continuare a lavorare. Se avete qualcosa che funziona, e non v'è alcuna buona ragione per riscriverlo, tenerlo.

Se alcuni dei vostri codice esistente ha bisogno l'aggiornamento a fare il suo lavoro, allora si sta guardando i costi di manutenzione. A questo punto è necessario per determinare se una riscrittura migliorerà i costi di manutenzione abbastanza per essere valsa la pena. Non dimenticate di sottrarre test e debug di nuovi bug perché ci saranno nuovi bug. Non respingere il codice di lavoro solo perché è vecchio.

Se il codice esistente è sufficientemente modulare, di solito si può sgretolare un pezzo alla volta. Riscrivere i componenti di manutenzione elevati prima.

Se si farà nuovo sviluppo in C #, allora si dovrebbe andare bene a lavorare con i componenti COM fino ad avere una giustificazione sufficiente per sostituirli.

Answer 2

I pensi di avere un buon piano. Questo sarà poi passare la maggior parte del codice in C #, approfittando del set di strumenti meglio.

Il codice VB6 comprendono oggetti COM?

Lei ha detto che il codice "non può essere fermato per una completa riscrittura". Ma non c'è bisogno di fermarsi. Uno dopo l'altro, è possibile sostituire ogni pezzo di funzionalità VB6 con il codice equivalente C #. Ciò consentirebbe di effettuare una modifica alla volta (preferibilmente con test automatizzati per dimostrare che non si è rotto niente).

Answer 3

Ri-scrivere su una base esigenze quando v'è un fattore motivante.

Un vecchio progetto Windows ho lavorato su avuto un motore di regole scritto in C che funzionava così abbiamo appena lasciato come una scatola nera DLL.

Abbiamo costruito un nuovo front-end e la base di utenti è stato rimasti colpiti dalla facile da usare nuovo look moderno dell'applicazione. Nessuna disposizione gli elementi interni aveva davvero cambiato.

Il livello di accesso ai database è stato utilizzato SQL Server DBLIB e non è stato ri-wrtten fino a quando abbiamo aggiornato SQL Server.

Answer 4

Ci sono diversi sistemi di questo tipo. La parte preoccupante di tutto questo è il ciclo di vita dello stato di supporto VB6 . V'è il rischio (per quanto piccolo), che non sarà in grado di ottenere aiuto da Microsoft con un problema bloccante con per esempio un aggiornamento del server futuro, e non avrà la capacità di risolvere da soli (per esempio, a causa di incompatibilità tra la VB6 DLL e il patch server di O / S). Questo è un rischio la gestione potrebbe essere interessato a - ma poi, se non si dispone di tutti gli accordi di supporto ora, forse stanno bene con questo?

Stiamo in realtà guardando la riscrittura e ridisegnare alcuni di quelli più critici. Abbiamo provato l'evoluzione incrementale, ed è in grado di lavorare, ma fa per una (diciamo) operazioni interessanti e situazione di manutenzione. Mi consiglia vivamente di strumentazione tutto (codice di vecchi e nuovi) con un sacco di registrazione configurabili, se non siete già, per aiutare con isolamento dei guasti.

COM suona come una ragionevole interfaccia tra legacy e nuovi. A meno che non si dispone di molto semplici interazioni tra i componenti, non posso davvero capire perché si desidera tornare a un meccanismo più semplice IPC. COM ha le sue complessità, ma fornisce anche un sacco di astrazioni utili per esempio tipizzazione dei dati e delle versioni che si avrebbe dovuto reinventare e mantenere ...

Answer 5

Penso che avete bisogno di guardare i vostri percorsi di aggiornamento per i vostri clienti. Il fatto è che ad un certo punto quando hanno 16 core CPU che si sta andando a voler concorrenza per accelerare le cose. In modo da avere un business case per allontanarsi forma VB6 e verso WCF. WCF ha un supporto incorporato concorrenza e sincronizzazione. Può essere usato per la comunicazione locale in-process nonché tra processi e la comunicazione tra computer. Essa ha anche il vantaggio di consentire di fare di più di programmazione stile AOP.

Answer 6

Al momento sono uno dei tanti sviluppatori che lavorano su un grande sistema legacy che era iniziato come una combinazione di C e C ++ con Win32 e, più tardi, MFC con un'infarinatura di assemblaggio tra il codice di back-end C. Recentemente abbiamo saltato da VC ++ 6 a Visual Studio 2005 (e da allora aggiornato al 2008) per l'ultima versione del progetto che stiamo lavorando. Dal momento che l'aggiornamento IDE / compilatore, stiamo pulendo alcuni l'aspetto grafico e sono stati l'aggiunta gestita C ++ con WinForms e ora C # con WCF.

Mentre i fondamenti del nostro sistema, compreso il back-end, sarà quasi sicuramente rimanere in C (almeno per il prossimo futuro), nulla di nuovo nel front-end sarà molto probabilmente essere fatto in C # / WCF. Quando abbiamo il tempo e / o necessità, abbiamo intenzione di iniziare a sostituire le parti più vecchie di front-end con equivalente C # / codice WCF.