Domanda

La mia azienda ha tonnellate di legacy le applicazioni scritte in VB6.

Siamo in transizione da spostare applicazioni VB6 .NET (3.5, in particolare).

Quale sarebbe la strategia migliore per muoversi forma VB6 a .NET?



NOTA:Di seguito l'aggiornamento dovrebbe andare a "Project Management" e non ha nulla a che fare con la domanda principale.

[AGGIORNAMENTO]:Grazie per il tuo feedback finora
Ora ci sono domanda più che pop-up sono

  1. come assegnare agli sviluppatori di sviluppare nuove applicazioni?
  2. Ci dovrebbe essere un apposito aggiornamento di divisione che la conversione applicazioni legacy a quelli nuovi?O dovrebbe ogni sviluppatore partecipare processo di conversione?
  3. Solo gli sviluppatori senior partecipare conversione?Junior gli sviluppatori?o misto?

Sembra che, più ci penso il problema, più domande solo show up.

È stato utile?

Soluzione

Chiaramente, questo è un impegno importante che coinvolgerà un sacco di lavoro.
Quindi il mio consiglio sarebbe quello di trattarlo come un progetto a lungo termine.

Avere un chiaro obiettivo in mente, che affronta temi importanti come la sicurezza, la resilienza, la manutenzione e il futuro delle applicazioni.

Una volta che questo è stato concordato dai supporti del palo, sviluppare un prototipo di sistema per verificare la tua ipotesi, in cui si può provare il C# vrs VB.net o MVC vrs Webforms.Vorrei assegnare i migliori sviluppatori per questo.

Quindi iniziare con un piccolo sistemi legacy e costruire i componenti di base che si re-impiego anche in altri settori.
In questa fase, iniziare con il vostro sviluppatori più esperti, ma tutti devono essere coinvolti e avere familiarità con il nuovo framework.
Questo garantirà a tutti sono addestrati allo stesso tempo, nessuno è lasciato dietro.
A seconda di quante applicazioni hai vorrei ruotare gli sviluppatori, in modo che tutti i sistemi che possono trarre beneficio.

Anche il nuovo lavoro deve essere fatto .net lingua non in VB6.

Gradualmente la conversione ciascuna delle vostre applicazioni legacy.(Vorrei solo la conversione, se sono cambiate o se c'è un chiaro vantaggio per loro aggiornamento.)

Questo dovrebbe dare un solido quadro di riferimento per l'uso di andare avanti, assicurando agli utenti la funzionalità non è ostacolato dalla migrazione.

Per esempio:
Ho lavorato presso una società che aveva circa 40 VB applicazioni.
Nel corso del tempo abbiamo migrato tutte queste C# e ora (5 anni dopo), abbiamo circa 150 applicazioni c# (all in .net 2.).

Questi tutti di condividere un quadro comune, che li rende facili da mantenere ed estendere, se necessario.

Altri suggerimenti

Provare a sostituire la funzionalità di base con COM abilitato .NET librerie."Svuotano" il VB6 apps spostando la funzionalità .NET bit per bit.

Attenzione completa riscrittura.Se sono golosissimi ", perché è un taglio pulito" - di solito follia sta davanti!Leggere "Lavorare Efficacemente con il Codice Legacy" di Michael Piume di preparazione.Anche se il libro non specificamente andare in "passaggio da una lingua a un'altra" mostra un sacco di mondo reale insidie che si possono incontrare.

Penso che tutti sviluppatore deve aver definito le fasce orarie in cui fanno la migrazione su applicazioni legacy che hanno sviluppato prima.Dal momento che si dispone già di dominio di conoscenza e di sapere che il problema di spazio che dovrebbe essere il più produttivo.

Qui è un adattamento del mio risposta a una simile domanda.

La conversione di programmi di grandi dimensioni automaticamente è una scelta migliore di riscrittura.E ' una trappola comune per iniziare con ottimismo la riscrittura di un grande pezzo di software, fare buoni progressi di fissaggio alcuni dei ben noti difetti nella vecchia architettura, e poi impantanarsi nella funzionalità che hai appena preso per scontato per anni.A questo punto il management iniziano a farsi duro, e tutto può diventare molto scomodo.

...ed ecco un post sul blog di un Microsofty che è d'accordo con me:

Molte aziende che ho lavorato con i primi giorni di .NET guardato prima di riscrittura guidato in parte da un forte desiderio di migliorare l'architettura sottostante e strutture di codice, allo stesso tempo, come si trasferirono .NET.Purtroppo molti di questi progetti imbattuto in difficoltà e molti non sono mai stati completati.Il problema si sta cercando di risolvere è troppo grande

Questo eccellente Microsoft pagina consiglia due terzi di strumenti di migrazione come meglio rispetto al sottodimensionato built-in VB.NET procedura guidata di aggiornamento - Artinsoft e CodeArchitects VBMigration.Artinsoft scritto il costruito nel VB.NET aggiornamento guidato, questa è la loro versione migliorata.E CodeArchitects è stata fondata da Francesco Balena, che ha scritto alcune delle libri classici VB6 e VB.NET.

La stessa pagina di Microsoft dice anche:

Esecuzione di una riscrittura completa per .NET è molto più costoso e difficile da fare bene [di conversione] ...noi possiamo solo raccomandare questo approccio per un piccolo numero di situazioni.


EDIT:Cantata dice nei commenti:"Io non sono un grande fan di generazione automatica di codice perché è più difficile eseguire il debug inizialmente e potrebbe prendere tutto il tempo necessario per riscrivere tutto".Devo dissentire fortemente.In generale anch'io sono un fan di generazione di codice, ma in questo caso il codice risultante sarà strutturato in modo identico all'originale VB6 e dovrebbe essere quasi completamente funzionale.Io in realtà non ho provato questi strumenti mi sono ancora, ma da loro cliente testimonianze questa promessa si compie.

E ripeto la Microsoft consigli appena al di sopra, sulla base della loro esperienza di assistere molti migrazioni - "una riscrittura completa, è di gran lunga più costoso e difficile di conversione [corsivo mio]" - un piatto contraddizione con l'ipotesi che potrebbe prendere il tempo stesso.Se si desidera migliorare la struttura del VB6, migrazione graduale poi refactoring è probabile che sia molto più conveniente rispetto a quello di una riscrittura.

Vedere questo:
https://stackoverflow.com/questions/507291/should-we-select-vb-net-or-c-when-upgrading-our-legacy-apps

Naturalmente, C# vs VB.Net è solo una parte di esso.

Per esempio, un'altra cosa da considerare sono se si desidera utilizzare questa opportunità per spostare le applicazioni su una rete intranet, se non l'hai già.O quanto in profondità si desidera approfondire lo stack di microsoft.È Winforms abbastanza o non si desidera utilizzare WPF, per esempio.

Vorrei iniziare con Microsoft strumenti:

http://msdn.microsoft.com/en-us/library/aa480541.aspx

Si potrebbe trovare il seguente articolo utile:http://www.vsj.co.uk/articles/display.asp?id=756

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top