Los miembros del equipo cuestionan pasar de VBA a C #

Fondo

El año pasado, me pidieron que creara una herramienta para la planificación de negocios para unos 10 usuarios. Esto se hizo en nombre de otro equipo de TI que me "subcontrató" el trabajo, y debido a que los plazos del proyecto no estaban planeados, tuve que implementarlo con un poco de prisa.

En ese momento, decidimos que la forma más rápida sería crear un libro de Excel con VBA y luego hacer que los usuarios descarguen este libro mejorado de VBA desde una Intranet para usar en sus PC. Excel fue una restricción en este caso porque el sistema de planificación (es decir, la base de datos) que usamos solo puede interactuar a través de un complemento de Excel que debe cargarse al mismo tiempo que el libro de planificación está abierto. Sin embargo, VBA no era una restricción en ese momento.

El libro de trabajo que creé alrededor de 4,000 líneas de código VBA y aunque intenté separar las capas de datos y de presentación, no pude en todos los casos debido a los plazos del proyecto. Para ser honesto, aunque estoy orgulloso de crear este libro de trabajo, al mismo tiempo estoy un poco decepcionado porque podría haberse hecho mejor, tanto en términos de codificación como de implementación para los usuarios.

Hoy

Volviendo a hoy, el equipo de TI volvió a pedirme un libro de trabajo similar (para poder reutilizar partes del otro libro de trabajo anterior), pero esta vez es mucho más complicado y será utilizado por un mayor número de usuarios ( alrededor de 200).

Sin embargo, esta vez, está un poco mejor planificado y puedo ver que tenemos un poco más de tiempo para planificar las cosas. En base a esto, pensé en la solución y la infraestructura, ya que la programación para 100 usuarios tiene más impacto que para 10 usuarios. Por lo tanto, le sugerí al equipo que quizás deberíamos considerar migrar el código existente a una solución C # para poder administrar el código de una manera más refinada. Todavía lo estoy considerando como un complemento escrito usando VSTO / Excel-DNA que luego se puede implementar en los usuarios.

Discutí esto con el equipo de TI hace dos semanas y todo parecía estar bien, hasta ayer recibí un correo electrónico de uno de los miembros del equipo (que no conoce VBA o C #) preguntando por qué deberíamos comenzar este nuevo proyecto en C # en lugar de usar el mismo enfoque que antes. Algunas de sus preocupaciones fueron:

• Es un proyecto bastante importante, por lo que debe funcionar: una solución C # no sería tan estable o funcionaría tan bien como la solución basada en VBA existente.
• Tendríamos que tirar lo que habíamos hecho en la solución VBA y recrearlo desde cero en C #.
• Alguien tendrá que admitir dos soluciones separadas, una en VBA y otra en C #. [en realidad, actualmente no tienen a nadie que los apoye, por lo general intervengo].

Ahora, puedo entender algunas de sus preocupaciones hasta cierto punto, pero necesito tomar una decisión sobre los próximos pasos y con qué volver a ellos. Personalmente, me gustaría implementar en C # porque siento que sería mejor para construir una solución "Enterprise" como esta. Además, me gustaría aprovechar esta oportunidad para repasar mis habilidades en C # ya que actualmente no soy tan competente en C # como lo soy VBA y me gustaría que un proyecto como este me lleve al "siguiente nivel".

Preparé una lista de puntos que podría usar para tratar de convencerlos de que una solución C # sería mejor para este proyecto, esto es lo que tengo hasta ahora:

• Examen de la unidad.
• Fuente de control.
• Documentación de código: para la transferencia de conocimiento a otras personas de apoyo.
• Mejores convenciones de codificación: puede usar cosas como ReSharper para exigir una mejor denominación y estructura.
• Mejor IDE: menos errores debido al resaltado de errores.
• Más modularidad a través de ensamblajes: puede promover la reutilización en herramientas futuras.
• Implementación administrada: puede controlar quién utiliza esta herramienta.

Pregunta: ¿Qué otros puntos podría agregar para convencerlos? ¿O estoy tratando de morder más de lo que puedo masticar con este proyecto? ¿Debo callarme y hacerlo en VBA de todos modos?

Soy consciente de que el simple hecho de mudarse a un nuevo idioma porque es "más nuevo" o visto como "más fresco" no debería ser una base para una decisión y, como tal, me he resistido a incluirlo como un punto de decisión: se trata de hechos.

Además, no estoy pidiendo una comparación literal entre C # y VBA como lenguajes, ya que hay muchas comparaciones en SO.

Los tres puntos que enumeró parecen justos:

Es un proyecto bastante importante, por lo que debe funcionar: una solución C # no sería tan estable o funcionaría tan bien como la solución basada en VBA existente.

De hecho, más tarde, usted dice: "Me gustaría aprovechar esta oportunidad para repasar mis habilidades de C # ya que actualmente no soy tan competente en C # como lo soy VBA " (énfasis mío).

En otras palabras, tiene una solución que funciona y pasó por pruebas intensivas de usuario. Desea lanzar todo esto y reescribir todo en un idioma que no conoce bien. ¿Ves el problema?

Tendríamos que tirar lo que habíamos hecho en la solución VBA y recrearlo desde cero en C #.

Me vienen a la mente cosas que nunca debes hacer . Estás lanzando el código, así como las pruebas del usuario. No es algo bueno

Alguien tendrá que admitir dos soluciones separadas, una en VBA y otra en C #. [en realidad, actualmente no tienen a nadie que los apoye, por lo general intervengo].

Si todavía se usara la versión VBA, la reescritura es incluso más problemática. ¿Por qué tendrías dos sistemas dispares que requieren tu atención, cuando es posible que solo tengas uno que ya funcione y al que puedas refactorizar y agregar funciones?

Algunos de sus puntos, por otro lado, pueden ser criticados:

• Examen de la unidad.

  También puedes probar tu proyecto actual. Si no hay un marco conveniente para eso, cree uno.

• Fuente de control.

  El control de origen se ocupa del texto. Su código actual es texto, por lo tanto, puede usar el control de origen para él.

  El lenguaje, el sistema operativo, el marco o el ecosistema son completamente irrelevantes. Puede (y debe) usar el control de origen para cualquier código que escriba: código en Visual Studio, o un fragmento de código que redacte en unos minutos en LINQPad, o scripts de PowerShell que automatizan una tarea, o esquema de base de datos , o macros de Excel.

• Documentación de código: para la transferencia de conocimiento a otras personas de apoyo.

  Convenido.

• Mejores convenciones de codificación: puede usar cosas como ReSharper para exigir una mejor denominación y estructura.

  Definir "mejor". ¿Existen convenciones de codificación para las macros de Excel? En caso afirmativo, úselos: no son mejores ni peores que cualquier otro. Si no, cree unos y publíquelos para que otras personas también puedan usarlos. Las respuestas a una pregunta publicada en 2010 parecen bastante decepcionantes, pero puede haber nuevas herramientas disponibles desde entonces.

  Tenga en cuenta que la parte importante de las convenciones de codificación es que deben aplicarse en commit.

• Mejor IDE: menos errores debido al resaltado de errores.

  Convenido. El hecho de que no podamos escribir macros en Visual Studio es muy lamentable.

• Más modularidad a través de ensamblajes: puede promover la reutilización en herramientas futuras.

  Estoy bastante seguro de que su producto actual también puede usar cierto grado de modularidad.

• Implementación administrada: puede controlar quién utiliza esta herramienta.

  Convenido.

En lugar de una reescritura completa, puede buscar una forma de mover progresivamente el código de la macro a un ensamblaje ordinario escrito en VB.NET. ¿Por qué en VB.NET? Tres razones:

• Hay menos diferencia entre VBA y VB.NET, ya que hay entre VBA y C #.

• Usted sabe VBA mejor, y esto solo es una buena razón para usar VB.NET en lugar de C #. Si desea "repasar sus habilidades de C #", hágalo con sus proyectos personales, no con asuntos críticos del negocio.

• Cualquier reescritura de un idioma a otro conduce a posibles errores. No necesitas eso para este proyecto.

Pasar a un ensamblado .NET puede brindarle el entorno conveniente de Visual Studio, con las prácticas pruebas unitarias, TFS y resaltado de errores que utiliza actualmente en otros proyectos.

Al mismo tiempo, si mueve su código paso a paso, no corre el riesgo de una reescritura completa (es decir, pasar cuatro meses creando algo que nadie quiere usar debido a la gran cantidad de nuevos errores). Por ejemplo, ¿necesitas trabajar en una característica específica? Piense primero cómo puede mover esta característica particular a .NET.

Esto es bastante similar a la refactorización. En lugar de reescribir todo porque aprendió algunos nuevos patrones de diseño y características del lenguaje, simplemente hace pequeños cambios en el código en el que trabaja en este momento.

Yo apoyaría ir a C #. Otros han cubierto tus puntos muy bien, así que no voy a repetir lo que han dicho. Definitivamente, hay muchas buenas razones para seguir con VBA.

Sin embargo , uno de mis empleadores hizo un trabajo impecable al crear documentación significativa. Tanto es así que las decisiones de diseño se escribieron realmente con justificación, ¡si tan solo todos los proyectos de software tuvieran eso! ¿Mi punto? Una de las decisiones de diseño fue "Estamos eligiendo escribir este programa en Java, porque el Sr. Tal y tal quiere poner x años de experiencia en Java en su currículum". Si esa es una buena razón para pasar a C #, entonces no se puede ignorar como una trivialidad. Simplemente no puede ser una de las razones que utiliza para justificarlo ante el equipo de TI, porque realmente no les importa lo que quiere en su currículum, sino el producto en funcionamiento.

También existe la percepción de VBA para pensar. Sé que no es cierto, pero conozco a algunas personas que ven 'VBA' en un currículum y piensan "¿Qué, este tipo estaba atrapado haciendo trabajo interno? ¿Por qué no tiene experiencia con un idioma real ?" Ven 'VBA' y piensan 'desarrollador macro excelente'. Como copiar / pegar una celda a otra, hacer cálculos simples, etc. Por lo general, el tipo de personas que pueden apreciar el desarrollo real en VBA son aquellos que lo han hecho, y eso parece un grupo cada vez más pequeño, al menos en mi experiencia. Es posible que tenga una mejor idea de la percepción de VBA en su área, pero he visto mucha negatividad injustificada hacia ella.

La otra cosa en la que quiero centrarme: MainMa mencionó las similitudes entre VBA y C #. Esto es absolutamente cierto, y la respuesta de JMK ofrece un par de tecnologías para leer. Intente copiar / pegar su código VBA en un proyecto de C # y vea lo fácil que parece corregir los errores de sintaxis.

Dijiste que tenías 4,000 líneas de código, lo cual es una buena porción de código y probablemente abarca mucha funcionalidad ... pero solo son 4,000 líneas de código. Prueba lo de copiar y pegar. Realmente no me sorprendería si pudiera limpiar esos errores de sintaxis y tener un proyecto que funcione. Sin conocer los detalles de su código o la cantidad de tiempo libre disponible para usted, creo que podría eliminar esto en un fin de semana.

Es posible que no siga las mejores prácticas de C #, puede ser ineficiente, pero terminaría con un proyecto funcionalmente equivalente en C #. También podría estar relativamente seguro de que su nuevo código C # no es más propenso a defectos que su antiguo código VBA.

Convertir su código VBA a C # en su propio tiempo haría un par de cosas por usted:

• A medida que investigue los errores de sintaxis, se familiarizará con las prácticas de C #, una especie de manual para trabajar realmente en C #
• Brindará una luz sobre cualquier problema obvio con la carga del complemento en Excel (dado que Excel presumiblemente sigue siendo un requisito). Quizás haya un problema que aún no haya considerado que pueda ser un obstáculo.
• Mostrará una prueba de concepto a su cliente (el equipo de TI). Si pueden ver que tiene un complemento de C # que funciona con la funcionalidad actual, reducirá su nivel de riesgo percibido con C #.

Y volviendo a los tres puntos de TI:

• Es un proyecto bastante importante, por lo que tiene que funcionar: una solución C # no sería tan estable o funcionaría tan bien como la solución basada en VBA existente.

Como se mencionó, su código C # cubrirá la misma funcionalidad y será tan estable como su VBA. Estrictamente hablando, no es una posibilidad introduces bugs / defectos o deficiencias, pero que parece poco probable. No estamos hablando de un puerto de iOS / Objective C a Android / Java, estamos hablando de un puerto entre dos lenguajes que comparten muchas similitudes en la sintaxis y pueden utilizar exactamente la misma tecnología: libros de Excel.

• Tendríamos que tirar lo que habíamos hecho en la solución VBA y recrearlo desde cero en C #.

Con esto, no estás desperdiciando ningún esfuerzo o código.

• Alguien tendrá que admitir dos soluciones separadas, una en VBA y otra en C #. [en realidad, actualmente no tienen a nadie que los apoye, por lo general intervengo].

Solo tendrá 1 solución, todo en C #.

En general, su cliente ve muchos riesgos. Si puede seguir los pasos para mitigar ese riesgo, podrían adoptar el cambio a C #.

Odio decirlo, pero sus argumentos simplemente no aguantan.

Examen de la unidad.

Este ha sido un problema resuelto durante mucho tiempo. Hay muchos marcos de prueba de unidad por ahí. Elegir uno. Deberías haber estado haciendo esto ya. Recomiendo el nuestro , porque se integra en el IDE y proporciona otras excelentes funciones.

Fuente de control

Esta es un poco más difícil, hay pocas soluciones preparadas, pero en realidad es solo cuestión de introducir y sacar su código de un repositorio. Aquí hay una forma sencilla de hacerlo , pero también hay otras mejores opciones .

Documentación del código

También un problema resuelto. MZ-Tools tiene una función de documentación XML que funciona de manera muy similar a los documentos de comentarios XML de .Net.

Mejores convenciones de codificación

Al igual que Visual Studio tiene el complemento ReSharper, tanto MZ-Tools como Rubberduck tienen tales características.

IDE mejor

Nuevamente, hay complementos disponibles para el IDE de VBA.

Más modularidad a través de ensamblajes: puede promover la reutilización en herramientas futuras.

También un problema resuelto. No, no puede crear ensamblajes, pero puede hacer referencia a otros proyectos de VBA.

Implementación administrada: puede controlar quién utiliza esta herramienta.

Una pequeña pegatina, necesitará escribir código para controlar quién puede acceder al programa y quién no, pero usted (nuevamente) probablemente ya debería haber escrito un código de seguridad.

En cuanto a la implementación, es también un problema resuelto. Sí, requiere código, pero hay ejemplos que puedes usar / modificar .

Además de todo esto, está el hecho de que comenzaría desde cero. Yo también recomendaré el artículo de Joel Spolsky .

Lo hicieron cometiendo el peor error estratégico que cualquier compañía de software puede cometer:

Decidieron reescribir el código desde cero.

Sus chicos de TI tienen razón. No deberías volver a escribir esto desde cero. Debería resolver los problemas con su solución actual.

Ahora, con todo lo dicho, puedo entender absolutamente por qué querrías hacer esto en C # o VB.Net. Realmente son una mejor solución, si está comenzando un nuevo proyecto , pero por lo que parece, no es un proyecto nuevo. Es mucho mejor mejorar lo que tienes que romperlo comenzando de nuevo.

Puede señalar que incluso Microsoft afirma en este artículo:

La actualización del código para mejorar las funciones o corregir errores requeriría que el artefacto de Office sea reenviado, reestructurado y reelaborado por cada usuario y en cada archivo que haya estado utilizando la personalización.

El artículo trata sobre diferentes enfoques de desarrollo de cosas basados ​​en Office, tal vez pueda tomar también otros pros y contras en su discusión.

Realmente depende de cómo va a pasar a C # (es decir, qué tecnología va a utilizar).

Si va a usar OpenXML, está hablando de una reescritura total que, si tiene una solución que funciona, no se recomienda.

Si está hablando de usar Interop, es posible que el proceso sea sorprendentemente fluido. He movido mucho código de VBA a C # (con Interop) en el pasado y una vez que está conectado al libro de trabajo, así:

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

En muchos casos, puede copiar / pegar su código VBA, anteponiendo llamadas a funciones workbook., reemplazando Dim con var, etc., según corresponda, y agregando puntos y comas al final.

Es esencialmente el mismo marco debajo (Excel), solo está cambiando la sintaxis de VBA a C #.

Cuando haya terminado, asegúrese de guardar y cerrar la aplicación:

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

Luego lanza la aplicación con el mariscal:

Marshal.ReleaseComObject(excelApplication);

Probablemente escribiría una clase de contenedor implementando IDisposable alrededor del objeto Aplicación de Excel, luego asegúrese de usarlo usingcuando se use este objeto.

Una buena manera de presentar su caso sería pasar una hora más o menos haciendo esto, lo que en un corto espacio de tiempo demostraría la rapidez con la que podría transferir el código y convencer a sus colegas de que es una buena idea.

El código no se modificaría en gran medida, pero tiene todos los beneficios que mencionó de tener un proyecto C # dentro de Visual Studio.

Estoy en la misma posición, de tener una aplicación muy grande (20k + líneas de código VBA) integrada en un libro de Excel. Al realizar pruebas con Office 2013, simplemente no funciona, debido a los cambios en la secuencia del evento de inicio en el nuevo modelo de oficina y posiblemente a una aplicación más estricta de EMET. Por lo tanto, estoy en condiciones de realizar una conversión forzada a C # y VB.NET antes del lanzamiento de Office 2013 este año. Otros libros de trabajo más simples (mejorados con VBA) utilizados en toda la organización no han sido inmunes, algunos funcionan y otros no.

Los errores se producen en el evento Workbook_Open , donde las hojas del libro ya no están disponibles, y en el código EXCEL interno antes de que se haga referencia a cualquier código VBA.

Estar cómodo en todos los VBA, C # y VB.NET Estoy escribiendo la conversión en los dos últimos. El código marco se está escribiendo en C # porque los modismos del lenguaje me permiten escribir ciertas construcciones funcionales en ese lenguaje 3-4 veces más rápido que en VB.NET. La mayor parte del código está en VB.NET porque mi reescritura es menos extensa y hay ciertos modismos que no están presentes en C #.

Antes de tomar cualquier decisión, le recomiendo que pruebe la aplicación existente con OFFICE 2013 y el alcance total de la aplicación de EMET que la organización prevé implementar en los próximos 2-3 años. Puede que, como yo, descubra que la aplicación existente simplemente no se ejecutará en ese entorno sin una reescritura de todos modos, en cuyo caso la reescritura también podría estar en DOT NET y VSTO.

Apéndice:

Escribir una pequeña utilidad de extracción automatizada, que recorre todo el contenido del libro de trabajo VBA y exporta todos los módulos, clases y formularios a archivos, es de 1-2 días de trabajo, dependiendo de lo elegante que desee que sea. Del mismo modo con el reverso para importar los archivos de un directorio a un libro en blanco. Con estos dos, es bastante posible tener todo su código VBA en el control de origen adecuado y tener un proceso de compilación a partir del código fuente para su libro de trabajo.

O - use una utilidad gratuita como Excel VBA Code Cleaner

Me gustaría aprovechar esta oportunidad para repasar mis habilidades en C # ya que actualmente no soy tan competente en C # como lo soy VBA y me gustaría que un proyecto como este me lleve al "siguiente nivel".

Se honesto. ¿Planea compartir esta información con las otras personas involucradas en la toma de esta decisión? De lo contrario, te echaría toda la culpa si el proyecto falla. Dado que un proyecto similar ya se ha creado y puesto en el campo, todos han formado lo que esperan que suceda en su propia mente. Saben cuánto tiempo llevó construir el último y creerán que puede crearlo en menos tiempo (lo que puede ser cierto o no según los requisitos adicionales). ¿Estás listo para asumir esta responsabilidad junto con aprender un nuevo idioma?

Recomiendo portar la aplicación anterior a C # lo antes posible. Tal vez pueda aprender lo suficiente en el proceso antes de tomar una decisión. Al menos lograrás tu objetivo de aumentar tus habilidades con el nuevo idioma y aún así terminar el proyecto a tiempo.

Por otra parte, si te sientes tan fuerte al respecto y la construcción del proyecto descansa sobre tus hombros, hazlo como quieras. Siempre es más fácil obtener el perdón que el permiso.