Interrogazione dei membri del team passando da VBA a C #

I tre punti che hai elencato sembrano equi:

It is a fairly important project so it has to work - a C# solution would not be as stable or work as well as the existing a VBA-based solution.

In effetti, più tardi, tu dici: "Vorrei cogliere questa opportunità sulle mie abilità in C # come Attualmente non sono competente in C # come sono VBA " (enfasi mia).

In altre parole, hai una soluzione che funziona e ha superato test intensivi dell'utente. Vuoi buttare tutto questo e riscrivere tutto in una lingua che non conosci bene. Vedi il problema?

We would have to throw away what we [I] had done in the VBA solution and recreate it from scratch in C#.

Cose che non dovresti mai fare ti viene in mente. Stai lanciando il codice, così come il test dell'utente. Non è una buona cosa.

Someone will have to support two separate solutions, one in VBA and one in C#. [actually, they currently do not have anyone for support, I usually step in].

Se la versione VBA fosse ancora utilizzata, la riscrittura è davvero ancora più problematica. Perché dovresti avere due sistemi diversi che richiedono la tua attenzione, quando potresti averne solo uno che funziona già e su cui puoi refactoring e aggiungere funzionalità?

Alcuni dei tuoi punti, d'altra parte, possono essere criticati:

• Test delle unità.

  Puoi testare anche il tuo progetto corrente. Se non esiste un framework conveniente, creane uno.

• Controllo del codice sorgente.

  Il controllo del codice sorgente riguarda il testo. Il tuo codice corrente è testo, quindi puoi utilizzare il controllo del codice sorgente per esso.

  La lingua, il sistema operativo, la struttura o l'ecosistema sono completamente irrilevanti. Puoi (e dovresti) utilizzare il controllo del codice sorgente per qualsiasi codice che scrivi: codice in Visual Studio o una parte di codice che disegni in pochi minuti in LINQPad o script PowerShell che automatizzano un'attività, o schema del database o macro di Excel.

• Documentazione del codice - per il trasferimento della conoscenza ad altre persone di supporto.

  D'accordo.

• Migliori convenzioni di codifica - possono utilizzare cose come ReSharper per rafforzare la denominazione e la struttura.

  Definisci "migliore". Esistono convenzioni di codifica per le macro di Excel? Se sì, usali: non sono migliori o peggiori di altri. In caso contrario, crearne e pubblicarle in modo che anche altre persone possano usarle. Le risposte a una domanda pubblicata nel 2010 sembrano piuttosto deludenti, ma potrebbero esserci nuovi strumenti disponibili da allora.

  Si noti che la parte importante delle convenzioni di codifica è che dovrebbero essere applicate al commit.

• IDE migliore: meno errori dovuti all'evidenziazione degli errori.

  D'accordo. Il fatto che non possiamo scrivere macro in Visual Studio è molto sfortunato.

• Più modularità attraverso gli assiemi - può promuovere il riutilizzo negli strumenti futuri.

  Sono abbastanza sicuro che il tuo attuale prodotto possa utilizzare anche un certo grado di modularità.

• Implementazione gestita: in grado di controllare con chi viene utilizzato questo strumento.

  D'accordo.

Invece di una completa riscrittura, puoi cercare un modo per progressivamente spostare il codice dalla macro a un assembly ordinario scritto in VB.NET. Perché in VB.NET? Tre motivi:

• C'è meno differenza tra VBA e VB.NET perché c'è tra VBA e C #.

• Tu conosci meglio VBA, e solo questo è un buon motivo per usare VB.NET invece di C #. Se vuoi "rispolverare le tue abilità in C #", fallo con i tuoi progetti personali, non con contenuti aziendali importanti.

• Qualsiasi riscrittura da una lingua a un'altra porta a potenziali bug. Non hai bisogno di questo per questo progetto.

Il passaggio a un assembly .NET può darti l'ambiente conveniente di Visual Studio, con il comodo test dell'unità, TFS e l'errore che evidenzia l'utilizzo corrente in altri progetti.

Allo stesso tempo, se si sposta il codice passo dopo passo, non si corre il rischio di una completa riscrittura (ad esempio trascorrendo quattro mesi creando qualcosa che nessuno desidera utilizzare a causa dell'elevato numero di nuovi bug). Ad esempio, è necessario lavorare su una funzione specifica? Pensa come puoi spostare questa particolare funzionalità su .NET.

Questo è abbastanza simile al refactoring. Invece di riscrivere il tutto perché hai imparato alcuni nuovi modelli di progettazione e funzionalità linguistiche, devi semplicemente apportare piccole modifiche al codice su cui lavori in questo momento.

Vorrei supportare andando a C #. Altri hanno coperto i tuoi punti molto bene, quindi non ripeterò ciò che hanno detto. Ci sono sicuramente molti buoni motivi per restare con VBA.

Tuttavia , uno dei miei datori di lavoro ha svolto un lavoro impeccabile nel creare una documentazione significativa. Tanto che le decisioni di design sono state effettivamente scritte con giustificazione - se solo tutti i progetti software avessero questo! Il mio punto? Una delle decisioni progettuali era "Abbiamo scelto di scrivere questo programma in Java, perché Mr. So-and-so vuole mettere x anni di esperienza Java sul suo curriculum". Se questo è un motivo valido per passare a C #, non può essere ignorato come banalità. Semplicemente non può essere uno dei motivi che usi per giustificare il fatto al team IT, perché a loro non interessa quello che vuoi sul tuo curriculum, a loro importa del prodotto funzionante.

C'è anche la percezione di VBA a cui pensare. So che non è vero, ma conosco un bel po 'di persone che vedono "VBA" su un curriculum e pensano "Cosa, questo ragazzo è rimasto bloccato a fare il tirocinio? Perché non ha esperienza con un reale lingua? " Vedono "VBA" e pensano "sviluppatore di macro Excel". Come copiare / incollare una cella a un'altra, fare semplici calcoli, ecc. Di solito il tipo di persone che possono apprezzare lo sviluppo reale in VBA sono quelli che l'hanno fatto, e che sembra un pool sempre più piccolo, almeno nella mia esperienza. Potresti avere un migliore senso della percezione di VBA nella tua zona, ma ho visto molta negatività ingiustificata nei suoi confronti.

L'altra cosa su cui voglio concentrarmi: MainMa ha menzionato le somiglianze tra VBA e C #. Questo è assolutamente vero, e la risposta di JMK offre un paio di tecnologie su cui leggere. Prova a copiare / incollare il tuo codice VBA in un progetto C # e scopri quanto è facile correggere gli errori di sintassi.

Hai detto che avevi 4000 linee di codice, che è una buona porzione di codice e probabilmente include molte funzionalità ... ma sono solo 4.000 linee di codice. Prova la copia e incolla la cosa. Non sarei davvero sorpreso se potessi ripulire quegli errori di sintassi e avere un progetto funzionante. Senza conoscere i dettagli del tuo codice o la quantità di tempo libero a tua disposizione, penserei che potresti metterlo fuori gioco in un fine settimana.

Potrebbe non seguire le best practice C #, potrebbe essere inefficiente, ma si finirebbe con un progetto funzionalmente equivalente in C #. Potresti anche essere relativamente certo che il tuo nuovo codice C # non è più soggetto a difetti rispetto al tuo vecchio codice VBA.

Convertire il tuo codice VBA in C # a tuo piacimento farebbe un paio di cose per te:

• Mentre esegui ricerche sugli errori di sintassi, acquisirai maggiore familiarità con le pratiche di C #: una sorta di primer che funziona effettivamente in C #
• Farà luce su eventuali problemi evidenti con il caricamento del plug-in in Excel (dal momento che Excel è presumibilmente ancora un requisito). Forse c'è un problema che non hai ancora considerato potrebbe essere un roadblock.
• Mostrerà un proof-of-concept al tuo cliente (il team IT). Se riescono a vedere che hai un plug-in C # funzionante con le funzionalità attuali, allora ridurrai il loro livello di rischio percepito con C #.

E tornando ai tre punti IT:

• It is a fairly important project so it has to work - a C# solution would not be as stable or work as well as the existing a VBA-based solution.

Come già detto, il tuo codice C # coprirà la stessa funzionalità e sarà stabile quanto il tuo VBA. A rigor di termini, è una possibilità di introdurre bug / difetti o inefficienze, ma ciò sembra improbabile. Non stiamo parlando di una porta da iOS / Objective C a Android / Java, stiamo parlando di una porta tra due lingue che condividono molte somiglianze nella sintassi e che possono utilizzare la stessa identica tecnologia: le cartelle di lavoro excel.

• We would have to throw away what we [I] had done in the VBA solution and recreate it from scratch in C#.

Con questo, non stai buttando via alcuno sforzo o codice.

• Someone will have to support two separate solutions, one in VBA and one in C#. [actually, they currently do not have anyone for support, I usually step in].

Avrai solo 1 soluzione, il tutto in C #.

Tutto sommato, il tuo cliente vede molti rischi. Se puoi prendere le misure per mitigare tale rischio, potrebbero abbracciare la modifica a C #.

Non oso dirlo, ma i tuoi argomenti non reggono l'acqua.

Test delle unità.

Questo è stato un problema risolto da molto tempo. Ci sono molti framework di testing unitario là fuori. Sceglierne uno. Avresti dovuto farlo già. Raccomando nostro , perché si integra nell'IDE e offre altre fantastiche funzionalità.

Controllo sorgente

Questo è un po 'più difficile, ci sono alcune soluzioni già pronte, ma è solo questione di ottenere il tuo codice dentro e fuori da un repository. Ecco un modo semplice per farlo , ma ci sono altre opzioni migliori .

Documentazione del codice

Anche un problema risolto. MZ-Tools ha una funzione di documentazione XML che funziona in modo molto simile ai documenti di commento XML di .Net

Migliori convenzioni di codifica

Proprio come Visual Studio ha il plug-in ReSharper, entrambi MZ-Tools e Rubberduck hanno queste caratteristiche.

IDE migliore

Anche in questo caso, sono disponibili plug-in per VBA IDE.

Più modularità attraverso gli assiemi - può promuovere il riutilizzo negli strumenti futuri.

Anche un problema risolto. No, non è possibile creare assiemi, ma è possibile fare riferimento ad altri progetti VBA.

Implementazione gestita: in grado di controllare con chi viene utilizzato questo strumento.

Un po 'di adesivo, dovrai scrivere un codice per controllare chi è in grado di accedere al programma e chi no, ma probabilmente (di nuovo) probabilmente dovresti avere scritto il codice di sicurezza.

Per quanto riguarda la distribuzione, è anche un problema risolto. Sì, richiede codice, ma ci sono esempi là fuori che potresti usare / modificare .

In cima a tutto questo, è il fatto che tu stia iniziando da zero. Anche io consiglierò l'articolo di Joel Spolsky .

They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.

I tuoi IT hanno ragione. Non dovresti riscriverlo da zero. Dovresti risolvere i problemi con la tua soluzione attuale.

Ora, con tutto ciò che ho detto, posso assolutamente capire perché vorresti farlo in C # o VB.Net. Sono davvero una soluzione migliore, se stai iniziando un nuovo progetto , ma dai suoni, non è un nuovo progetto. È molto meglio migliorare ciò che hai allora per romperlo ricominciando da capo.

Puoi sottolineare che anche Microsoft afferma in questo articolo:

Updating the code to improve features or to fix bugs would require that the Office artifact be re-emailed, re-structured, and re-worked by every single user and in every single file that has been using the customization.

L'articolo tratta di approcci diversi allo sviluppo di materiale basato su Office, forse puoi prendere anche altri pro e contro nella tua discussione.

Dipende molto da come intendi passare a C # (ovvero quale tecnologia utilizzerai).

Se stai per utilizzare OpenXML, allora stai parlando di una riscrittura totale che, se hai una soluzione che funziona, non è raccomandata.

Se stai parlando di usare Interop, potresti scoprire che il processo è sorprendentemente scorrevole. Ho spostato un sacco di codice da VBA a C # (con Interop) in passato e una volta che sei collegato alla cartella di lavoro, in questo modo:

var excelApplication = new Application();
var workbook = excelApplication.Workbooks.Open(@"C:\location.xlsx");

In molti casi puoi copiare / incollare il tuo codice VBA, prefissare le chiamate di funzione con workbook. , sostituire Dim con var etc dove appropriato e aggiungere punto e virgola su Alla fine.

È essenzialmente lo stesso Framework sottostante (Excel), stai semplicemente cambiando la sintassi da VBA a C #.

Quando hai finito, assicurati di salvare e chiudere l'applicazione:

workbook.Save();
excelApplication.Quit();

Quindi rilascia l'applicazione con Maresciallo:

Marshal.ReleaseComObject(excelApplication);

Probabilmente scriverei una classe wrapper che implementasse IDisposable attorno all'oggetto Application Excel, quindi assicurati di usare using quando questo oggetto viene usato.

Un buon modo per rendere il tuo caso sarebbe quello di trascorrere un'ora o così facendo, che in un breve lasso di tempo dimostrerebbe quanto velocemente si può portare il codice attraverso e convincere i colleghi che questa è una buona idea.

Il codice rimarrebbe in gran parte invariato in un certo senso, ma hai tutti i vantaggi che hai menzionato di avere un progetto C # in Visual Studio.

Sono nella stessa posizione, di avere un'applicazione molto grande (20k + linee di codice VBA) incorporata in una cartella di lavoro EXCEL. Durante i test con Office 2013 semplicemente non riesce a funzionare, si ritiene necessario a causa dei cambiamenti nella sequenza di eventi di avvio nel nuovo modello di ufficio e, eventualmente, di un'applicazione più rigorosa di EMET. Sono quindi nella posizione di fare una conversione in crash in C # e VB.NET prima del roll-out di Office 2013 quest'anno. Altri, più semplici (VBA enhanced) cartelle di lavoro utilizzate in tutta l'organizzazione non sono stati immuni, alcuni funzionanti e altri no.

Gli errori si verificano nell'evento Workbook_Open , in cui i fogli della cartella di lavoro non sono più disponibili e nel codice EXCEL interno prima che venga fatto riferimento a qualsiasi codice VBA.

Essere a proprio agio in tutto VBA, C # e VB.NET Sto scrivendo la conversione in entrambi gli ultimi due. Il codice del framework è stato scritto in C # perché gli idiomi del linguaggio mi permettono di scrivere certi costrutti funzionali in quella lingua 3-4 volte più velocemente che in VB.NET. La maggior parte del codice è in VB.NET perché poi la mia riscrittura è meno estesa e ci sono alcuni idiomi che non sono presenti in C #.

Prima di prendere qualsiasi decisione, raccomando vivamente di testare l'applicazione esistente con UFFICIO 2013 e la misura più ampia di applicazione EMET che l'organizzazione prevede di implementare nei prossimi 2-3 anni. Potresti, come me, scoprire che l'applicazione esistente semplicemente non funzionerà in quell'ambiente senza riscrivere comunque, nel qual caso la riscrittura potrebbe essere anche in DOT NET e VSTO.

Addendum:

Scrivendo una piccola utility di estrazione automatica, che scorre attraverso l'intero contenuto della VBA della cartella di lavoro ed esporta tutti i moduli, le classi e le forme in file, è di 1-2 giorni di lavoro, a seconda di quanto vuoi che sia. Allo stesso modo con il retro per importare i file da una directory in una cartella di lavoro vuota. Con questi due è possibile avere tutto il codice VBA nel giusto controllo del codice sorgente e avere un processo Build dal codice sorgente della cartella di lavoro.

OPPURE - utilizza un'utilità gratuita come Pulitore di codice VBA di Excel

I would like to take this opportunity brush up on my C# skills as I am currently not as competent in C# as I am VBA and I'd like a project like this to take me to the "next level".

Sii onesto. pensi di condividere queste informazioni con le altre persone coinvolte nel prendere questa decisione? Altrimenti, darei tutta la colpa a te se il progetto fallisse. Poiché un progetto simile è già stato creato e messo in campo, tutti hanno formato ciò che si aspettano di accadere nella loro mente. Sanno quanto tempo ci è voluto per costruire l'ultimo e credono che tu possa crearlo in meno tempo (il che può o non può essere vero in base ai requisiti aggiuntivi). Sei pronto ad assumerti questa responsabilità insieme all'apprendimento di una nuova lingua?

Raccomando di trasferire la vecchia app su C # ASAP. Forse puoi imparare abbastanza nel processo prima di prendere una decisione. Almeno raggiungerai il tuo obiettivo di aumentare le tue abilità con la nuova lingua e ottenere comunque il progetto in tempo.

Poi di nuovo, se ti senti così strong e costruisci il progetto, tutto si appoggia alle tue spalle, fallo nel modo che preferisci. È sempre più facile ottenere il perdono che il permesso.