Question d'un membre de l'équipe passant de VBA à C #

Contexte

L'année dernière, on m'a demandé de créer un outil à utiliser pour la planification d'entreprise pour une dizaine d'utilisateurs. Cela a été fait au nom d'une autre équipe informatique qui m'a "sous-traité" le travail, et en raison des échéances du projet un peu imprévues de leur côté, j'ai dû le mettre en œuvre en un clin d'œil.

À l'époque, nous avons décidé que le moyen le plus rapide serait de créer un classeur Excel avec VBA, puis de demander aux utilisateurs de télécharger ce classeur amélioré VBA à partir d'un intranet pour l'utiliser sur leur PC. Excel était une contrainte dans ce cas car le système de planification (c'est-à-dire la base de données) que nous utilisons ne peut interagir que via un complément Excel qui doit être chargé en même temps que le classeur de planification est ouvert. Cependant, VBA n'était pas une contrainte à l'époque.

Le classeur, j'ai créé environ 4 000 lignes de code VBA et alors que j'essayais de séparer les couches de données et de présentation, je n'ai pas pu dans tous les cas en raison des délais du projet. Pour être honnête, alors que je suis fier de créer ce classeur, je suis en même temps un peu déçu car il aurait pu être mieux fait, tant en termes de codage qu'en termes de déploiement auprès des utilisateurs.

Aujourd'hui

Retour à aujourd'hui et l'équipe informatique est venue me demander à nouveau un classeur similaire (afin que je puisse réutiliser des parties de l'autre classeur ci-dessus), mais cette fois, c'est beaucoup plus compliqué et sera utilisé par un plus grand nombre d'utilisateurs ( environ 200).

Cependant, cette fois, c'est un peu mieux planifié et je peux voir que nous avons un peu plus de temps pour planifier les choses. Sur cette base, j'ai pensé à la solution et à l'infrastructure car la programmation pour 100 utilisateurs a plus d'impact que pour 10 utilisateurs. Par conséquent, j'ai suggéré à l'équipe que nous devrions peut-être envisager de migrer le code existant vers une solution C # afin de pouvoir gérer le code de manière plus raffinée. Je le considère toujours comme un complément écrit en utilisant VSTO / Excel-DNA qui peut ensuite être déployé auprès des utilisateurs.

J'ai discuté de cela avec l'équipe informatique il y a deux semaines et tout semblait aller bien, jusqu'à hier, j'ai reçu un courrier de l'une des équipes (qui ne connaît pas VBA ou C #) me demandant pourquoi nous devrions commencer ce nouveau projet en C # plutôt que d'utiliser le même approche que précédemment. Certaines de leurs préoccupations étaient les suivantes:

• C'est un projet assez important, donc il doit fonctionner - une solution C # ne serait pas aussi stable ou fonctionnerait aussi bien que la solution existante basée sur VBA.
• Nous devions jeter ce que nous [j'avais] fait dans la solution VBA et le recréer à partir de zéro en C #.
• Quelqu'un devra prendre en charge deux solutions distinctes, une en VBA et une en C #. [en fait, ils n'ont actuellement personne pour le soutien, j'interviens habituellement].

Maintenant, je peux comprendre certaines de leurs préoccupations dans une certaine mesure, mais je dois prendre une décision sur les prochaines étapes et sur quoi leur revenir. Personnellement, j'aimerais l'implémenter en C # car je pense que cela se prêterait mieux à la construction d'une solution "Entreprise" comme celle-ci. De plus, je voudrais saisir cette opportunité pour parfaire mes compétences en C # car je ne suis pas actuellement aussi compétent en C # que je suis VBA et j'aimerais qu'un projet comme celui-ci me fasse passer au "niveau supérieur".

J'ai préparé une liste de points que je pourrais utiliser pour essayer de les convaincre qu'une solution C # serait mieux pour ce projet, c'est ce que j'ai jusqu'à présent:

• Tests unitaires.
• Contrôle de source.
• Documentation du code - pour le transfert de connaissances à d'autres personnes de soutien.
• Meilleures conventions de codage - peuvent utiliser des éléments tels que ReSharper pour appliquer une meilleure dénomination et une meilleure structure.
• Meilleur IDE - moins d'erreurs dues à la mise en évidence des erreurs.
• Plus de modularité grâce aux assemblages - peut favoriser la réutilisation dans les futurs outils.
• Déploiement géré - peut contrôler qui est utilisé par cet outil.

Question: Quels autres points pourrais-je ajouter pour les convaincre? Ou est-ce que j'essaie de mordre plus que je ne peux mâcher avec ce projet? Dois-je simplement me taire et le faire en VBA de toute façon?

Je suis conscient que le simple fait de passer à une nouvelle langue parce que sa «nouvelle» ou sa «fraîcheur» ne devrait pas servir de base à une décision et en tant que tel, j'ai résisté à l'inclure comme point de décision - il s'agit de faits.

En outre, je ne demande pas de comparaison littérale entre C # et VBA en tant que langages, car il existe de nombreuses comparaisons sur SO.

Les trois points que vous avez énumérés semblent justes:

C'est un projet assez important, donc il doit fonctionner - une solution C # ne serait pas aussi stable ou fonctionnerait aussi bien que la solution existante basée sur VBA.

En effet, plus tard, vous dites: "Je voudrais profiter de cette occasion pour parfaire mes compétences en C # car je ne suis pas actuellement aussi compétent en C # que je suis VBA " (c'est moi qui souligne).

En d'autres termes, vous avez une solution qui fonctionne et qui a subi des tests utilisateurs intensifs. Vous voulez jeter tout cela et tout réécrire dans une langue que vous ne connaissez pas bien. Vous voyez le problème?

Nous devions jeter ce que nous [j'avais] fait dans la solution VBA et le recréer à partir de zéro en C #.

Ce que vous ne devriez jamais faire vous vient à l'esprit. Vous lancez le code, ainsi que les tests utilisateur. Pas une bonne chose.

Quelqu'un devra prendre en charge deux solutions distinctes, une en VBA et une en C #. [en fait, ils n'ont actuellement personne pour le soutien, j'interviens habituellement].

Si la version VBA était toujours utilisée, la réécriture est en effet encore plus problématique. Pourquoi auriez-vous deux systèmes disparates qui nécessitent votre attention, alors que vous n'en avez qu'un seul qui fonctionne déjà et auquel vous pouvez refactoriser et ajouter des fonctionnalités?

En revanche, certains de vos points peuvent être critiqués:

• Tests unitaires.

  Vous pouvez également tester en bloc votre projet actuel. S'il n'y a pas de cadre pratique pour cela, créez-en un.

• Contrôle de source.

  Le contrôle des sources traite du texte. Votre code actuel est du texte, vous pouvez donc utiliser le contrôle de code source pour cela.

  La langue, le système d'exploitation, le cadre ou l'écosystème sont complètement hors de propos. Vous pouvez (et devez) utiliser le contrôle de code source pour tout code que vous écrivez: du code dans Visual Studio, ou un morceau de code que vous rédigez en quelques minutes dans LINQPad, ou des scripts PowerShell qui automatisent une tâche, un schéma de base de données ou des macros Excel.

• Documentation du code - pour le transfert de connaissances à d'autres personnes de soutien.

  D'accord.

• Meilleures conventions de codage - peuvent utiliser des éléments tels que ReSharper pour appliquer une meilleure dénomination et une meilleure structure.

  Définissez «mieux». Existe-t-il des conventions de codage pour les macros d'Excel? Si oui, utilisez-les: ils ne sont ni meilleurs ni pires que les autres. Sinon, créez-en un et publiez-le afin que d'autres personnes puissent également l'utiliser. Les réponses à une question posée en 2010 semblent plutôt décevantes, mais de nouveaux outils peuvent être disponibles depuis lors.

  Notez que la partie importante des conventions de codage est qu'elles doivent être appliquées lors de la validation.

• Meilleur IDE - moins d'erreurs dues à la mise en évidence des erreurs.

  D'accord. Le fait que nous ne puissions pas écrire de macros dans Visual Studio est très regrettable.

• Plus de modularité grâce aux assemblages - peut favoriser la réutilisation dans les futurs outils.

  Je suis sûr que votre produit actuel peut également utiliser un certain degré de modularité.

• Déploiement géré - peut contrôler qui est utilisé par cet outil.

  D'accord.

Au lieu d'une réécriture complète, vous pouvez rechercher un moyen de déplacer progressivement le code de la macro vers un assembly ordinaire écrit en VB.NET. Pourquoi dans VB.NET? Trois raisons:

• Il y a moins de différence entre VBA et VB.NET qu'il y a entre VBA et C #.

• Vous connaissez mieux VBA, et cela seul est une bonne raison d'utiliser VB.NET au lieu de C #. Si vous voulez "parfaire vos compétences en C #", faites-le avec vos projets personnels, pas avec des affaires critiques.

• Toute réécriture d'une langue dans une autre entraîne des bugs potentiels. Vous n'en avez pas besoin pour ce projet.

Le passage à un assembly .NET peut vous offrir l'environnement pratique de Visual Studio, avec les tests unitaires pratiques, TFS et la mise en évidence des erreurs que vous utilisez actuellement dans d'autres projets.

Dans le même temps, si vous déplacez votre code étape par étape, vous ne prenez pas le risque d'une réécriture complète (c'est-à-dire passer quatre mois à créer quelque chose que personne ne veut utiliser à cause du nombre élevé de nouveaux bugs). Par exemple, vous devez travailler sur une fonctionnalité spécifique? Réfléchissez à la façon dont vous pouvez d'abord déplacer cette fonctionnalité particulière vers .NET.

Ceci est assez similaire au refactoring. Au lieu de réécrire le tout parce que vous avez appris de nouveaux modèles de conception et de nouvelles fonctionnalités de langage, vous effectuez simplement de petites modifications sur le code sur lequel vous travaillez actuellement.

Je soutiendrais le passage à C #. D'autres ont très bien couvert vos points, donc je ne vais pas répéter ce qu'ils ont dit. Il y a certainement beaucoup de bonnes raisons de rester avec VBA.

Cependant , un de mes employeurs a fait un travail impeccable pour créer une documentation significative. Tant et si bien que les décisions de conception ont été écrites avec justification - si seulement tous les projets logiciels en avaient! Mon point? L'une des décisions de conception a été "Nous choisissons d'écrire ce programme en Java, parce que M. Untel veut mettre x ans d'expérience Java sur son CV". Si c'est une bonne raison pour vous de passer en C #, cela ne peut pas être ignoré comme une trivialité. Cela ne peut tout simplement pas être l'une des raisons que vous utilisez pour le justifier auprès de l'équipe informatique, car ils ne se soucient pas vraiment de ce que vous voulez sur votre CV, ils se soucient du produit qui fonctionne.

Il faut aussi penser à la perception de VBA. Je sais que ce n'est pas vrai, mais je connais pas mal de gens qui voient «VBA» sur un curriculum vitae et pensent «Quoi, ce gars était coincé à faire un travail de stagiaire? Pourquoi n'a-t-il pas d'expérience avec une vraie langue? Ils voient 'VBA' et pensent 'excel macro developer'. Comme copier / coller d'une cellule à une autre, faire des calculs simples, etc. Habituellement, le genre de personnes qui peuvent apprécier un vrai développement dans VBA sont celles qui l'ont fait, et cela semble être un pool de plus en plus petit, du moins d'après mon expérience. Vous pourriez avoir une meilleure idée de la perception de VBA dans votre région, mais j'ai vu beaucoup de négativité injustifiée à son égard.

L'autre chose sur laquelle je veux me concentrer: MainMa a mentionné les similitudes entre VBA et C #. C'est absolument vrai, et la réponse de JMK offre quelques technologies pour lire. Essayez de copier / coller votre code VBA dans un projet C # et voyez à quel point les erreurs de syntaxe semblent faciles à corriger.

Vous avez dit que vous aviez 4 000 lignes de code, ce qui est un bon morceau de code et englobe probablement beaucoup de fonctionnalités ... mais ce n'est que 4 000 lignes de code. Essayez le copier-coller. Je ne serais vraiment pas surpris si vous pouviez nettoyer ces erreurs de syntaxe et avoir un projet fonctionnel. Sans connaître les détails de votre code ou le temps libre dont vous disposez, je pense que vous pourriez l'assommer en un week-end.

Il peut ne pas suivre les meilleures pratiques C #, il peut être inefficace, mais vous vous retrouveriez avec un projet fonctionnellement équivalent en C #. Vous pouvez également être relativement certain que votre nouveau code C # n'est pas plus sujet aux défauts que votre ancien code VBA.

Convertir votre code VBA en C # sur votre propre temps ferait deux choses pour vous:

• En recherchant les erreurs de syntaxe, vous vous familiariserez avec les pratiques C # - une sorte d'amorce pour réellement travailler en C #
• Cela mettra en lumière tous les problèmes évidents liés au chargement du plug-in dans Excel (car Excel est probablement encore une exigence). Peut-être y a-t-il un problème que vous n'avez pas encore examiné et qui pourrait être un barrage routier.
• Il montrera une preuve de concept à votre client (l'équipe informatique). S'ils peuvent voir que vous disposez d'un plug-in C # fonctionnel avec les fonctionnalités actuelles, alors vous réduirez leur niveau de risque perçu avec C #.

Et revenons aux trois points de l'informatique:

• C'est un projet assez important, il doit donc fonctionner - une solution C # ne serait pas aussi stable ou ne fonctionnerait pas aussi bien que la solution existante basée sur VBA.

Comme mentionné, votre code C # couvrira les mêmes fonctionnalités et sera tout aussi stable que votre VBA. À strictement parler, il est possible que vous introduisiez des bogues / défauts ou inefficacités, mais cela semble peu probable. Nous ne parlons pas d'un port d'iOS / Objective C à Android / Java, nous parlons d'un port entre deux langages qui partagent beaucoup de similitudes de syntaxe et peuvent utiliser exactement la même technologie - les classeurs Excel.

• Nous devions jeter ce que nous avions fait dans la solution VBA et le recréer à partir de zéro en C #.

Avec cela, vous ne jetez aucun effort ou code.

• Quelqu'un devra prendre en charge deux solutions distinctes, une en VBA et une en C #. [en fait, ils n'ont actuellement personne pour le soutien, j'interviens habituellement].

Vous n'aurez qu'une seule solution, toutes en C #.

Dans l'ensemble, votre client voit beaucoup de risques. Si vous pouvez prendre les mesures pour atténuer ce risque, ils pourraient accepter le changement en C #.

Je déteste le dire, mais vos arguments ne tiennent tout simplement pas.

Tests unitaires.

Cela a été un problème résolu depuis très longtemps. Il existe de nombreux cadres de tests unitaires. Choisissez-en un. Vous auriez déjà dû faire ça. Je recommande le nôtre , car il s'intègre à l'IDE et offre d'autres fonctionnalités intéressantes.

Contrôle de source

Celui-ci est un peu plus difficile, il existe peu de solutions prêtes à l'emploi, mais il s'agit vraiment simplement de faire entrer et sortir votre code d'un référentiel. Voici une façon de faire les sourcils bas , mais il existe également d' autres meilleures options .

Documentation du code

Également un problème résolu. MZ-Tools possède une fonctionnalité de documentation XML qui fonctionne de manière très similaire aux documents de commentaires XML de .Net.

Meilleures conventions de codage

Tout comme Visual Studio a le plugin ReSharper, MZ-Tools et Rubberduck ont tous deux de telles fonctionnalités.

Meilleur IDE

Encore une fois, des plug-ins sont disponibles pour l'IDE VBA.

Plus de modularité grâce aux assemblages - peut favoriser la réutilisation dans les futurs outils.

Également un problème résolu. Non, vous ne pouvez pas créer d'assemblys, mais vous pouvez référencer d'autres projets VBA.

Déploiement géré - peut contrôler qui est utilisé par cet outil.

Un petit autocollant, vous devrez écrire du code pour contrôler qui peut accéder au programme et qui ne le peut pas, mais vous (probablement) devriez déjà avoir déjà écrit un code de sécurité.

Quant au déploiement, c'est aussi un problème résolu. Oui, cela nécessite du code, mais il existe des exemples que vous pouvez utiliser / modifier .

En plus de tout cela, il y a le fait que vous partiriez de zéro. Je recommanderai moi aussi l'article de Joel Spolsky .

Ils l'ont fait en faisant la pire erreur stratégique que n'importe quelle entreprise de logiciels puisse faire:

Ils ont décidé de réécrire le code à partir de zéro.

Vos informaticiens ont raison. Vous ne devriez pas réécrire cela à partir de zéro. Vous devriez résoudre les problèmes avec votre solution actuelle.

Maintenant, avec tout cela dit, je peux absolument comprendre pourquoi vous voudriez le faire en C # ou VB.Net. Ils sont vraiment une meilleure solution, si vous démarrez un nouveau projet , mais d'après les sons, ce n'est pas un nouveau projet. Il vaut mieux améliorer ce que vous avez, puis le casser en recommençant.

Vous pouvez souligner que même Microsoft déclare dans cet article:

La mise à jour du code pour améliorer les fonctionnalités ou corriger les bogues nécessiterait que l'artefact Office soit envoyé par e-mail, restructuré et retravaillé par chaque utilisateur et dans chaque fichier qui a utilisé la personnalisation.

L'article traite de différentes approches de développement de trucs basés sur Office, vous pouvez peut-être également en tirer d'autres avantages et inconvénients dans votre discussion.

Cela dépend vraiment de la façon dont vous avez l'intention de passer au C # (c'est-à-dire de la technologie que vous allez utiliser).

Si vous allez utiliser OpenXML, vous parlez d'une réécriture totale qui, si vous avez une solution qui fonctionne, n'est pas recommandée.

Si vous parlez d'utiliser Interop, vous constaterez peut-être que le processus est étonnamment fluide. J'ai déplacé beaucoup de code de VBA vers C # (avec Interop) dans le passé et une fois que vous êtes connecté au classeur, comme ceci:

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

Dans de nombreux cas, vous pouvez copier / coller votre code VBA, préfixer les appels de fonction avec workbook., remplacer Dim par var, etc., le cas échéant, et ajouter des points-virgules à la fin.

C'est essentiellement le même Framework en dessous (Excel), vous changez simplement la syntaxe de VBA en C #.

Lorsque vous avez terminé, assurez-vous de sauvegarder et de fermer l'application:

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

Relâchez ensuite l'application avec le maréchal:

Marshal.ReleaseComObject(excelApplication);

J'écrirais probablement une classe wrapper implémentant IDisposable autour de l'objet Application Excel, puis assurez-vous de l'utiliser usinglorsque cet objet est utilisé.

Une bonne façon de faire valoir votre point de vue serait de passer environ une heure à le faire, ce qui, dans un court laps de temps, démontrerait la rapidité avec laquelle vous pourriez porter du code, et convaincre vos collègues que c'est une bonne idée.

Le code resterait en grande partie inchangé dans un sens, mais vous avez tous les avantages que vous avez mentionnés d'avoir un projet C # dans Visual Studio.

Je suis dans la même position, d'avoir une très grande application (20k + lignes de code VBA) intégrée dans un classeur EXCEL. Lors des tests avec Office 2013, il ne fonctionne tout simplement pas, supposé en raison de changements dans la séquence des événements de démarrage dans le nouveau modèle de bureau, et peut-être d'une application plus stricte d'EMET. Je suis donc en mesure de faire un crash-conversion en C # et VB.NET avant le déploiement d'Office 2013 cette année. D'autres classeurs plus simples (améliorés par VBA) utilisés dans l'organisation n'ont pas été immunisés, certains fonctionnant et d'autres non.

Les erreurs se produisent dans l' événement Workbook_Open , où les feuilles du classeur ne sont plus disponibles, et dans le code EXCEL interne avant tout code VBA référencé.

Étant à l'aise dans tous les VBA, C # et VB.NET, j'écris la conversion dans les deux derniers. Le code du framework est écrit en C # parce que les idiomes du langage me permettent d'écrire certaines constructions fonctionnelles dans ce langage 3 à 4 fois plus rapidement qu'en VB.NET. La majeure partie du code se trouve dans VB.NET car ma réécriture est alors moins étendue et il y a certains idiomes qui ne sont pas présents en C #.

Avant de prendre une décision, je vous recommande fortement de tester l'application existante avec OFFICE 2013 et la mesure la plus complète d'application d'EMET que l'organisation prévoit de déployer au cours des 2-3 prochaines années. Vous pourriez, comme moi, découvrir que l'application existante ne fonctionnera tout simplement pas dans cet environnement sans réécriture de toute façon - auquel cas la réécriture pourrait tout aussi bien être dans DOT NET et VSTO.

Addenda:

Écrire un petit utilitaire d'extraction automatisé, qui parcourt l'intégralité du contenu du classeur VBA et exporte tous les modules, classes et formulaires dans des fichiers, prend 1-2 jours, selon la fantaisie que vous souhaitez. De même avec l'inverse pour importer les fichiers d'un répertoire vers un classeur vierge. Avec ces deux , il est tout à fait possible d'avoir tout votre code VBA dans le contrôle de bonne source, et d'avoir un Mensuration processus à partir du code source de votre classeur.

OU - utilisez un utilitaire gratuit tel que Excel VBA Code Cleaner

Je voudrais saisir cette opportunité pour parfaire mes compétences en C # car je ne suis pas actuellement aussi compétent en C # que je suis VBA et j'aimerais qu'un projet comme celui-ci me fasse passer au "niveau supérieur".

Être honnête. Envisagez-vous de partager ces informations avec les autres personnes impliquées dans la prise de cette décision? Sinon, je vous imputerais toute la responsabilité si le projet échoue. Puisqu'un projet similaire a déjà été créé et mis sur le terrain, tout le monde a formé ce qu'il attend de lui dans son esprit. Ils savent combien de temps il a fallu pour créer le dernier et croiront que vous pouvez créer celui-ci en moins de temps (ce qui peut ou non être vrai en fonction des exigences supplémentaires). Êtes-vous prêt à assumer cette responsabilité tout en apprenant une nouvelle langue?

Je recommande de porter l'ancienne application sur C # ASAP. Vous pouvez peut-être en apprendre suffisamment dans le processus avant qu'une décision ne soit prise. Au moins, vous atteindrez votre objectif d'augmenter vos compétences avec la nouvelle langue et réaliserez toujours le projet à temps.

Là encore, si vous vous sentez si fort à ce sujet et que la construction du projet repose sur vos épaules, faites-le comme vous le souhaitez. Il est toujours plus facile d'obtenir le pardon que la permission.