Come continuate a sviluppare grandi sistemi software (a lungo termine) con legacy e nuovo codice?

Question

Io lavoro su una base di codice grande con una base di installazione di grandi dimensioni di utenti. Il codice è stato originariamente scritto in vb6 con alcuni moduli COM C++ per lavori di basso livello.

È completamente impossibile riscrivere tutto il codice che è già stato scritto in vb6 e viene utilizzato quotidianamente dai nostri clienti, ma stiamo anche continuando a apportare miglioramenti e personalizzazioni al software (grandi e piccoli).

La mia soluzione finora è scrivere la maggior parte del nuovo codice in C# (winform e anche wpf ora) e quindi utilizzare l'interoperabilità COM per chiamare i moduli da vb6.

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

Answer 1

È difficile dare una singola risposta onnicomprensiva, ma l'approccio di alto livello è chiaro. Almeno, questo è l'approccio che ho usato. Dare priorità ai tuoi obiettivi e quindi cercare di identificare i costi per raggiungere tali obiettivi. I tuoi costi si ridurranno essenzialmente a "tempi di sviluppo".

In primo luogo, vuoi che tutto funzioni per continuare a funzionare. Se hai qualcosa che funziona, e non c'è una buona ragione per riscriverlo, tienilo.

Se alcuni dei codici esistenti devono essere aggiornati per svolgere il proprio lavoro, si stanno esaminando i costi di manutenzione. A questo punto è necessario determinare se una riscrittura migliorerà i costi di manutenzione tanto da valerne la pena. Non dimenticare di sottrarre test e debug di nuovi bug perché ci saranno nuovi bug. Non ignorare il codice di lavoro solo perché è vecchio.

Se il codice esistente è sufficientemente modulare, di solito è possibile eliminarlo un pezzo alla volta. Riscrivi innanzitutto i componenti di alta manutenzione.

Se si sta facendo un nuovo sviluppo in C#, si dovrebbe lavorare bene con i componenti COM fino a quando non si ha una giustificazione sufficiente per sostituirli.

Answer 2

Penso che sia necessario esaminare i percorsi di aggiornamento per i propri clienti. Il fatto è che a un certo punto, quando hanno 16 CPU core, vorrai che la concorrenza acceleri le cose. Quindi hai un business case per allontanarti da VB6 e verso WCF. WCF ha integrato il supporto per la concorrenza e la sincronizzazione. Può essere utilizzato per la comunicazione locale in-proc e per le comunicazioni cross-process e cross-machine. Ha anche il vantaggio di permetterti di fare più programmazione in stile AOP.

Answer 3

Penso che tu abbia un buon piano. Questo alla fine trasferirà la maggior parte del codice in C#, sfruttando il set di strumenti migliore.

Il codice VB6 comprende oggetti COM?

Hai detto che il codice "non può essere fermato per una completa riscrittura". Ma non devi fermarti. Uno per uno, è possibile sostituire ogni parte della funzionalità VB6 con il codice C# equivalente. Questo ti permetterebbe di fare un cambiamento alla volta (preferibilmente con test automatici per dimostrare che non hai rotto nulla).

Answer 4

Riscrivere su una base di esigenze quando c'è un fattore motivante.

Un vecchio progetto di Windows su cui ho lavorato aveva un motore di regole scritto in C che funzionava, quindi l'abbiamo lasciato come una black box DLL.

Abbiamo creato un nuovo front-end e la base di utenti è rimasta colpita dal nuovo look moderno dell'applicazione. Nulla negli interni era davvero cambiato.

Il livello di accesso al database utilizzava SQL Server DBLIB e non è stato re-wrtten fino a quando non abbiamo aggiornato SQL Server.

Answer 5

Attualmente sono uno dei numerosi sviluppatori che lavorano su un grande sistema legacy che è iniziato come una combinazione di C e C++ con Win32 e, successivamente, MFC con un'infarinatura di assembly tra il codice C back end. Di recente siamo passati da VC++ 6 a Visual Studio 2005 (e da allora abbiamo aggiornato al 2008) per l'ultima versione del progetto su cui stiamo lavorando. Dall'aggiornamento IDE/compilatore, abbiamo eliminato parte dell'aspetto e aspetto e abbiamo aggiunto C++ gestito con WinForms e ora C# con WCF.

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

Answer 6

Abbiamo diversi sistemi di questo tipo. La parte preoccupante di tutto ciò è il lifecycle support status of VB6. Esiste il rischio (per quanto piccolo) che non sarà possibile ottenere aiuto da Microsoft con un problema di showstopper con ad es. un futuro aggiornamento del server e non sarà in grado di risolverlo da soli (ad esempio, a causa di incompatibilità tra le DLL VB6 e il server O/S con patch). Questo è un rischio a cui la tua gestione potrebbe essere interessata - ma poi, se non hai ora nessun accordo di supporto, forse sono a loro agio con quello?

In realtà stiamo cercando di riscrivere e ridisegnare alcuni dei più critici. Abbiamo provato l'evoluzione incrementale, e può funzionare, ma crea una situazione operativa e di manutenzione (diciamo) interessante. Consiglio vivamente di strumentare tutto (vecchio e nuovo codice) con un sacco di logging configurabile, se non lo siete già, per aiutare con l'isolamento dei guasti.

COM sembra una ragionevole interfaccia tra eredità e nuova. A meno che tu non abbia interazioni molto semplici tra componenti, non riesco davvero a capire perché vorresti tornare a un meccanismo IPC più basilare. COM ha le sue complessità, ma fornisce anche molte utili astrazioni per es. digitando dati e versioni che avresti dovuto reinventare e mantenere ...