Domande dei membri del team che si spostano da VBA a C #

sfondo

L'anno scorso mi è stato chiesto di creare uno strumento da utilizzare per la pianificazione aziendale per circa 10 utenti. Ciò è stato fatto per conto di un altro team IT che mi ha "subappaltato" il lavoro e, dato che le scadenze del progetto erano un po 'non pianificate dalla loro parte, ho dovuto implementarlo in un attimo.

Al momento, abbiamo deciso che il modo più rapido sarebbe stato quello di creare una cartella di lavoro Excel con VBA e quindi far scaricare agli utenti questa cartella di lavoro potenziata con VBA da una Intranet da utilizzare sul proprio PC. In questo caso Excel era un vincolo perché il sistema di pianificazione (ovvero il database) che utilizziamo può interagire solo tramite un componente aggiuntivo di Excel che deve essere caricato contemporaneamente alla cartella di lavoro di pianificazione. Tuttavia, VBA non era un vincolo in quel momento.

La cartella di lavoro ho creato circa 4.000 righe di codice VBA e mentre provavo a separare i livelli di dati e presentazione, non potevo in tutti i casi a causa delle scadenze del progetto. Ad essere onesti, mentre sono orgoglioso di creare questa cartella di lavoro, sono allo stesso tempo un po 'deluso dal fatto che avrebbe potuto essere fatto meglio, sia in termini di codifica che di distribuzione agli utenti.

Oggi

Torna ad oggi e il team IT è tornato da me per richiedere una cartella di lavoro simile (in modo da poter riutilizzare parti dell'altra cartella di lavoro sopra), ma questa volta è molto più complicato e verrà utilizzato da un numero maggiore di utenti ( circa 200).

Tuttavia, questa volta, è un po 'meglio pianificato e posso vedere che abbiamo un po' più di tempo per pianificare le cose. Sulla base di questo, ho pensato alla soluzione e all'infrastruttura poiché la programmazione per 100 utenti ha un impatto maggiore rispetto a 10 utenti. Pertanto, ho suggerito al team che forse dovremmo considerare la migrazione del codice esistente in una soluzione C # in modo da poter gestire il codice in un modo più raffinato. Lo sto ancora considerando come un componente aggiuntivo scritto utilizzando VSTO / Excel-DNA che può quindi essere distribuito agli utenti.

Ne ho discusso due settimane fa con il team IT e tutto sembrava andare bene, fino a ieri ho ricevuto una mail da uno dei team (che non conosce VBA o C #) in cui si chiedeva perché avremmo dovuto iniziare questo nuovo progetto in C # anziché usare il stesso approccio di prima. Alcune delle loro preoccupazioni erano:

• È un progetto abbastanza importante, quindi deve funzionare: una soluzione C # non sarebbe stabile o funzionante come quella esistente basata su VBA.
• Dovremmo buttare via ciò che [I] abbiamo fatto nella soluzione VBA e ricrearlo da zero in C #.
• Qualcuno dovrà supportare due soluzioni separate, una in VBA e una in C #. [attualmente non hanno nessuno come supporto, di solito intervengo].

Ora, posso capire alcune delle loro preoccupazioni in una certa misura, ma devo prendere una decisione sui prossimi passi e su cosa tornare con loro. Personalmente, vorrei implementare in C # perché penso che si presterebbe meglio alla costruzione di una soluzione "Enterprise" come questa. Inoltre, vorrei cogliere l'occasione per rispolverare le mie abilità in C # poiché al momento non sono così competente in C # come lo sono VBA e vorrei che un progetto come questo mi portasse al "livello successivo".

Ho preparato un elenco di punti che potrei usare per provare a convincerli che una soluzione C # sarebbe migliore per questo progetto, questo è quello che ho finora:

• Test unitari.
• Controllo della fonte.
• Documentazione del codice - per il trasferimento di conoscenze ad altre persone di supporto.
• Convenzioni di codifica migliori: possono usare cose come ReSharper per applicare nomi e strutture migliori.
• IDE migliore: meno errori dovuti all'evidenziazione degli errori.
• Più modularità attraverso gli assiemi: può promuovere il riutilizzo in strumenti futuri.
• Distribuzione gestita: può controllare da chi viene utilizzato questo strumento.

Domanda: quali altri punti posso aggiungere per convincerli? O sto cercando di mordere più di quanto riesca a masticare con questo progetto? Dovrei solo tacere e farlo in VBA comunque?

Sono consapevole che il semplice passaggio a una nuova lingua perché "nuova" o vista come "più fredda" non dovrebbe costituire una base per una decisione e come tale ho resistito a includerla come un punto di decisione - si tratta di fatti.

Inoltre, non sto chiedendo un confronto letterale tra C # e VBA come lingue, poiché ci sono molti confronti su SO.

I tre punti che hai elencato sembrano equi:

È un progetto abbastanza importante, quindi deve funzionare: una soluzione C # non sarebbe stabile o funzionante come quella esistente basata su VBA.

In effetti, in seguito, dirai: "Vorrei cogliere l'occasione per ripassare le mie abilità in C # in quanto non sono attualmente competente in C # come lo sono VBA " (sottolineo il mio).

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

Dovremmo buttare via ciò che [I] abbiamo fatto nella soluzione VBA e ricrearlo da zero in C #.

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

Qualcuno dovrà supportare due soluzioni separate, una in VBA e una in C #. [attualmente non hanno nessuno come supporto, di solito intervengo].

Se la versione VBA sarebbe 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 al quale puoi riformattare e aggiungere funzionalità?

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

• Test unitari.

  Puoi anche testare l'unità del tuo progetto attuale. Se non esiste un framework conveniente per questo, crearne uno.

• Controllo della fonte.

  Il controllo del codice sorgente si occupa del testo. Il tuo codice attuale è testo, quindi puoi usare il controllo del codice sorgente per esso.

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

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

  Concordato.

• Convenzioni di codifica migliori: possono usare cose come ReSharper per applicare nomi e strutture migliori.

  Definisci "meglio". Esistono convenzioni di codifica per le macro di Excel? Se sì, usali: non sono migliori o peggiori di nessun altro. Altrimenti, creane uno e pubblicalo in modo che anche altre persone possano usarlo. Le risposte a una domanda pubblicata nel 2010 sembrano piuttosto deludenti, ma da allora potrebbero essere disponibili nuovi strumenti.

  Si noti che la parte importante delle convenzioni di codifica è che devono essere applicate su commit.

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

  Concordato. Il fatto che non possiamo scrivere macro in Visual Studio è molto sfortunato.

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

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

• Distribuzione gestita: può controllare da chi viene utilizzato questo strumento.

  Concordato.

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

• C'è meno differenza tra VBA e VB.NET in quanto c'è tra VBA e C #.

• Si sa VBA meglio, e questo da solo è una buona ragione per usare VB.NET invece di C #. Se vuoi "rispolverare le tue abilità in C #", fallo con i tuoi progetti personali, non con le cose fondamentali per il business.

• Qualsiasi riscrittura da una lingua a un'altra porta a potenziali bug. Non è necessario per questo progetto.

Il passaggio a un assembly .NET può offrire il comodo ambiente di Visual Studio, con il comodo test unitario, TFS e l'evidenziazione degli errori attualmente in uso in altri progetti.

Allo stesso tempo, se si sposta il codice passo dopo passo, non si corre il rischio di una riscrittura completa (vale a dire passare quattro mesi a creare qualcosa che nessuno vuole usare a causa dell'elevato numero di nuovi bug). Ad esempio, devi lavorare su una funzione specifica? Pensa come spostare prima questa particolare funzionalità in .NET.

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

Sosterrei andare a C #. Altri hanno coperto molto bene i tuoi punti, 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 nella creazione di documentazione significativa. Tanto che le decisioni di progettazione sono state effettivamente scritte con giustificazione - se solo tutti i progetti software lo avessero! Il mio punto? Una delle decisioni di progettazione è stata "Stiamo scegliendo 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 giustificarlo al team IT, perché a loro non importa davvero quello che vuoi sul tuo curriculum, si preoccupano 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 era bloccato a fare un lavoro da stagista? Perché non ha esperienza con un linguaggio vero ?" Vedono "VBA" e pensano "excel macro developer". Come copiare / incollare una cella in un'altra, fare semplici calcoli, ecc. Di solito il tipo di persone che possono apprezzare il vero sviluppo in VBA sono quelle 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 vedi quanto gli errori di sintassi sembrano facili da correggere.

Hai detto di avere 4.000 righe di codice, che è un buon pezzo di codice e probabilmente include molte funzionalità ... ma sono solo 4.000 righe di codice. Prova la cosa copia e incolla. Non sarei davvero sorpreso se potessi eliminare 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, penso che potresti metterlo da parte in un fine settimana.

Potrebbe non seguire le migliori pratiche di 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 # al tuo tempo farebbe un paio di cose per te:

• Man mano che esegui ricerche sugli errori di sintassi, acquisirai maggiore familiarità con le pratiche di C #, una sorta di primer per lavorare effettivamente in C #
• Farà luce su eventuali ovvi problemi 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 che potrebbe essere un blocco.
• Mostrerà una prova di concetto al tuo cliente (il team IT). Se riescono a vedere che hai un plug-in C # funzionante con le funzionalità correnti, ridurrai il loro livello di rischio percepito con C #.

E tornando ai tre punti dell'IT:

• È un progetto abbastanza importante, quindi deve funzionare: una soluzione C # non sarebbe stabile o funzionante come quella esistente basata su VBA.

Come accennato, il tuo codice C # coprirà le stesse funzionalità ed è stabile quanto il tuo VBA. A rigor di termini, non v'è una possibilità che introdurre bug / difetti o inefficienze, ma che sembra improbabile. Non stiamo parlando di una porta da iOS / Obiettivo C ad Android / Java, stiamo parlando di una porta tra due lingue che condividono molte somiglianze nella sintassi e possono utilizzare la stessa identica tecnologia: le cartelle di lavoro Excel.

• Dovremmo buttare via ciò che [I] abbiamo fatto nella soluzione VBA e ricrearlo da zero in C #.

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

• Qualcuno dovrà supportare due soluzioni separate, una in VBA e una in C #. [attualmente non hanno nessuno come supporto, di solito intervengo].

Avrai solo 1 soluzione, tutto in C #.

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

Odio dirlo, ma i tuoi argomenti semplicemente non trattengono l'acqua.

Test unitari.

Questo è stato un problema risolto per molto tempo. Esistono molti framework di unit test. Sceglierne uno. Avresti dovuto farlo già. Raccomando il nostro , perché si integra nell'IDE e offre altre fantastiche funzionalità.

Controllo della fonte

Questo è un po 'più difficile, ci sono alcune soluzioni già pronte, ma in realtà è solo una questione di far entrare e uscire il tuo codice da un repository. Ecco un modo basso per farlo , ma ci sono anche altre opzioni migliori .

Documentazione sul 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.

Convenzioni di codifica migliori

Proprio come Visual Studio ha il plug-in ReSharper, sia MZ-Tools che Rubberduck hanno tali funzionalità.

IDE migliore

Ancora una volta, ci sono plug-in disponibili per l'IDE VBA.

Più modularità attraverso gli assiemi: può promuovere il riutilizzo in strumenti futuri.

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

Distribuzione gestita: può controllare da chi viene utilizzato questo strumento.

Un po 'di adesivo, dovrai scrivere il codice per controllare chi è in grado di accedere al programma e chi non può, ma probabilmente (di nuovo) dovresti già aver scritto un codice di sicurezza.

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

In cima a tutto questo, sta il fatto che inizieresti da zero. Anche io consiglierò l'articolo di Joel Spolsky .

Lo hanno fatto facendo il peggior singolo errore strategico che qualsiasi azienda di software può fare:

Decisero di riscrivere il codice da zero.

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

Ora, con tutto ciò 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 di esso, non è un nuovo progetto. È molto meglio migliorare ciò che hai e poi romperlo ricominciando da capo.

Puoi sottolineare che anche Microsoft afferma in questo articolo:

L'aggiornamento del codice per migliorare le funzionalità o correggere i bug richiederebbe che il manufatto di Office venga rinviato, riformulato e rielaborato da ogni singolo utente e in ogni singolo file che ha utilizzato la personalizzazione.

L'articolo parla di diversi approcci per lo sviluppo di contenuti basati su Office, forse puoi anche prendere alcuni altri vantaggi e svantaggi nella tua discussione.

Dipende molto da come intendi passare a C # (ovvero quale tecnologia stai per utilizzare).

Se hai intenzione di utilizzare OpenXML, stai parlando di una riscrittura totale che, se hai una soluzione che funziona, non è consigliata.

Se stai parlando di usare Interop, potresti scoprire che il processo è sorprendentemente semplice. Ho spostato molto codice da VBA a C # (con Interop) in passato e una volta inserito nella 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 ecc ove appropriato e aggiungere punti e virgola alla fine.

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

Al termine, assicurati di salvare e chiudere l'applicazione:

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

Quindi rilascia l'applicazione con il Maresciallo:

Marshal.ReleaseComObject(excelApplication);

Probabilmente scriverei una classe wrapper implementando IDisposable attorno all'oggetto Applicazione Excel, quindi assicurati di usare usingquando questo oggetto viene utilizzato.

Un buon modo per sostenere il tuo caso sarebbe quello di dedicare circa un'ora a farlo, il che in breve tempo dimostrerebbe la velocità con cui potresti trasferire il codice e convincere i tuoi colleghi che questa è una buona idea.

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

Sono nella stessa posizione, di avere un'applicazione molto grande (20k + righe di codice VBA) incorporata in una cartella di lavoro EXCEL. Dopo aver testato con Office 2013, semplicemente non funziona, creduto a causa di cambiamenti nella sequenza di eventi di avvio nel nuovo modello di ufficio e forse di un'applicazione più rigorosa di EMET. Sono quindi nella posizione di fare una conversione in crash in C # e VB.NET prima del lancio di Office 2013 quest'anno. Altre cartelle di lavoro più semplici (potenziate con VBA) utilizzate all'interno dell'organizzazione non sono state immuni, alcune funzionano e altre 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 del riferimento a qualsiasi codice VBA.

Essere a mio agio in tutti VBA, C # e VB.NET Sto scrivendo la conversione in entrambi gli ultimi due. Il codice del framework viene scritto in C # perché gli idiomi del linguaggio mi consentono di scrivere determinati costrutti funzionali in quella lingua 3-4 volte più velocemente rispetto a VB.NET. La maggior parte del codice è in VB.NET perché quindi la mia riscrittura è meno estesa e ci sono alcuni modi di dire che non sono presenti in C #.

Prima di prendere qualsiasi decisione, ti consiglio vivamente di testare l'applicazione esistente con OFFICE 2013 e la massima misura di applicazione EMET che l'organizzazione prevede di implementare nei prossimi 2-3 anni. Come me, potresti scoprire che l'applicazione esistente semplicemente non funzionerà in quell'ambiente senza una riscrittura, nel qual caso la riscrittura potrebbe anche essere in DOT NET e VSTO.

Addendum:

Scrivere una piccola utility di estrazione automatica, che scorre l'intero contenuto della cartella di lavoro VBA ed esporta tutti i moduli, le classi e i moduli in file, richiede 1-2 giorni di lavoro, a seconda della fantasia che desideri. Allo stesso modo con il contrario per importare i file da una directory in una cartella di lavoro vuota. Con questi due è del tutto possibile avere tutto il codice VBA nel controllo del codice sorgente corretto e disporre di un processo di generazione dal codice sorgente per la cartella di lavoro.

OPPURE: utilizzare un'utilità gratuita come Excel VBA Code Cleaner

Vorrei cogliere l'occasione per rispolverare le mie abilità in C # poiché al momento non sono competente in C # come lo sono VBA e vorrei che un progetto come questo mi portasse al "livello successivo".

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

Consiglio di eseguire il porting della vecchia app su C # APPENA POSSIBILE. Forse puoi imparare abbastanza nel processo prima che venga presa una decisione. Almeno raggiungerai il tuo obiettivo di accrescere le tue abilità con la nuova lingua e farai comunque eseguire il progetto in tempo.

Poi di nuovo, se ti senti così forte e costruire il progetto è tutto sulle tue spalle, fallo nel modo che preferisci. È sempre più facile ottenere il perdono che il permesso.