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.