Converti un team da VB.Net a C # .Net

Se al momento hai sviluppatori VB.NET che conoscono C #, non penso che tutte e 20 le applicazioni debbano essere riscritte tutte in una volta. È solo troppa codifica, test, lancio e per cosa? Perché i tuoi prossimi assunti non capiranno il codice? Non confondere i programmatori C # che odiano VB con il loro non essere in grado di capirlo affatto o con poco addestramento.

Farei quanto segue:

1. Le nuove app vengono codificate in C #.
2. Le app attuali che richiedono modifiche significative, vengono convertite in C #.
3. I nuovi assunti devono imparare qualche VB anche se è un modo per convertire il codice o fare piccoli problemi. Hanno comunque bisogno di imparare i sistemi. Non gestiranno il codice di produzione il primo giorno. Avere un piano per salire a bordo. Se hanno disprezzo per VB, è un grande incentivo per convertirlo. Se ci sono nuovi progetti non troppo grandi, potrebbero essere coinvolti in questi. VB dev è solo una parte del loro lavoro per un periodo di tempo limitato. Non lasciare che si sentano bloccati per sempre.
4. Determina le app che probabilmente non avranno mai bisogno di essere convertite. Questo potrebbe cambiare nel tempo. Assicurati che questo sia sufficiente per il team attuale da gestire. Potresti avere alcune app eliminate gradualmente.

Un piano a lungo termine in cui si affrontano le cose secondo necessità e si converte in blocchi più piccoli non sembrerà un progetto così travolgente. Portare su 3 nuovi sviluppatori è un compito importante. Non convertire il codice solo per convertirlo. Potresti avere app che nessuno guarderà mai più.

Invece di cercare di dirti cosa dovresti fare, condividerò ciò che abbiamo fatto.

1. I test vengono scritti in C #, perché, siamo onesti, il codebase VB non ne ha.
2. Le nuove classi sono scritte in C # all'interno di nuovi progetti di librerie di classi aggiunti alle soluzioni.
3. Piccole modifiche al codice VB esistente vengono mantenute in VB, ma i test di caratterizzazione vengono aggiunti prima che vengano apportate modifiche.
4. Riflettitore spietato.
5. Una volta ottenuta una copertura di test significativa, puoi scegliere di migrare le classi VB nelle tue nuove librerie ogni volta che è conveniente, un po 'alla volta.
6. Ritirare il maggior numero di app / funzionalità possibili.
7. Non toccare alcun codice se non hai un requisito reale da parte di un utente per farlo. (C'è un concetto in Lean Manufacturing, non fare nulla finché un cliente non ti dà una ragione per farlo. Ti tratterà bene qui.)

Prima o poi, avremo un VB molto basso in un progetto e una copertura di prova abbastanza buona da "finirlo" e riscrivere il sottile strato della GUI. Dagli un bel lifting mentre ci sei. Questo approccio ha funzionato molto bene per la mia squadra.

Parte di quel codice VB sarà ancora presente in 2 decenni? Sì, ma non importa se nessuno ha mai bisogno di cambiarlo. Sii rispettoso dei soldi del tuo datore di lavoro. Rewrites raramente va bene. Se sei non preoccupato per i soldi della compagnia, quindi considera il tuo bonus ....

The question (for clarity, as it seems some couldn't read the question in its entirety): What is the best approach for migrating a team from VB.Net to C# with all of the considerations above?

La migrazione di una squadra è un problema, la migrazione di una base di codice esistente è un'altra.

Per quanto riguarda la tua base di codice , la risposta di @ JeffO è davvero buona.

Riguardo al tuo team , dal momento che il tuo team attuale è già a suo agio con C #, non vedo molti problemi, ma tieni presente che C # potrebbe avere alcune convenzioni diverse rispetto a VB.Net e, mentre condividono lo stesso framework, gli sviluppatori che vengono con lo sfondo VB6 di solito hanno standard diversi rispetto agli sviluppatori che hanno background C / C ++ / Java.

Per scopi di confronto: Convenzioni di codifica C # contro Convenzioni di codifica VB.Net .

Se ti aspetti di assumere sviluppatori C # più esperti e vuoi mantenerli nella tua squadra, sarebbe bello favorire l'adozione delle convenzioni C # tra il tuo team attuale mentre lavori con il nuovo codebase o il refactoring del vecchio codebase . È una questione di cultura, che a volte è difficile cambiare in una squadra ben stabilizzata.

C # e VB.Net sono lingue abbastanza simili, ma vuoi comunque ridurre il più possibile il rischio.

Ci sono strumenti che possono eseguire la traduzione in modo semi-automatico.

Dovresti fare un progetto alla volta, dal momento che un progetto è l'unità più piccola che puoi tradurre. Questo riduce il rischio e ti darà una buona idea di quanto tempo ci vorrà, quali problemi incontrerai e così via.

Dovresti non esternalizzare la traduzione o assumere uno sviluppatore dedicato per la traduzione. Piuttosto, gli sviluppatori che hanno già familiarità con il codice dovrebbero eseguire la traduzione. Dal momento che conoscono già entrambe le lingue, ciò assicurerà una transizione fluida e conosceranno il codice tradotto.

Non tentare un refactoring o ristrutturazione del codice nello stesso passaggio. Traduci 1: 1 anche se questo significa scrivere "VB in C #", basandosi sull'assembly Microsoft.VisualBasic e così via. Vuoi assicurarti che la traduzione abbia avuto successo senza problemi, prima di iniziare a riscrivere in uno stile C # più idiota.

La risposta di Machado punta già alle convenzioni sulla codifica e alla cultura. Vorrei sottolineare che uno sviluppatore C # che non vuole lavorare su codice VB non sarà soddisfatto con VB convertito in "C #" che in realtà è ancora VB.

Assicurati che il tuo team comprenda e viva i concetti di orientamento agli oggetti. Mettono il codice a cui appartiene? Separano le preoccupazioni (ad esempio l'interfaccia utente e la logica aziendale)? Capiscono SOLID? Capiscono come interagire con gli oggetti (schemi di progettazione, inversione di dipendenza)? Ecc.

È vero che ci sono molti sviluppatori C # che non lo sanno e sarà importante scoprirlo durante le interviste. Ma quelli che conoscono questi concetti potrebbero voler lasciarti presto se nessun altro li osserva.

Bene, potresti leggerlo al contrario: trova gli sviluppatori C # che non conoscono questi concetti e rimani con quello che viene detto essere codice VB tipico (sebbene sia stato "convertito" in C #) ...