martes, 17 de julio de 2012

La aplicación de buenas prácticas de desarrollo de software a VBA y Access (y las herramientas, también!)

[Traducción Automatica]

Después de trabajar con TSQL casi exclusivamente durante los últimos seis meses, llegó el momento en que el mes pasado tuve que hacer cambios en el código de Microsoft Access a una aplicación front-end en el trabajo.

Sobre la base de lo que he aprendido en los últimos años, más o menos con respecto al desarrollo de software en. NET, decidí armarme para hacer frente a código heredado en una plataforma y el lenguaje notoriamente conocido por no ser ideal para el desarrollo de software.

IDE Herramientas

Me topé con MZ-Tool un plugin para el IDE de Visual Basic Editor y wow! Este hizo toda la diferencia del mundo. Fue muy agradable encontrar una herramienta gratuita para inyectar un poco de ReSharper -ish apoyo a la rígida IDE de VBA. El producto Aparentemente se inició en el mundo de VB \ VBA y cuándo. NET vino fue llevado a Visual Studio.NET . (En realidad, puede ser considerado como un competidor directo a Re #. Tenga en cuenta que la versión de. NET no es gratis.)

Aquí están las características que se utilizan activamente durante la codificación:
  • Reemplazar en todos los proyectos - Esto fue enorme, ya que me permitió realizar realmente la técnica de refactorización, "Cambiar nombre", con varios niveles de control. Lo que realmente hizo posible que es el La vista real del árbol visual del código en el texto que desea cambiar se muestra como además de mostrar lo que la función / sub donde se puede encontrar bajo. Yo no tenía miedo de cambiar realmente nombres de las cosas que estaban bien torpe, confusa o anticuada en el estilo de codificación en nombres mucho más significativos. Al final, tuve un miedo significativamente menor en romper el código. (Esta función es equivalente a Re # 'Buscar sintaxis avanzada')
  • llamadas de procedimientos - similares a Re # 'Mostrar todos los usos "de un método o variable (y también es navegable a través de una vista de árbol visual)
  • Plantillas de código - Esto me permite crear y almacenar de forma permanente el código repetitivo que necesitaba para probar el código utilizando VBLiteUnit (ver próxima sección). Esta característica me abrió los ojos a más utilizan activamente y crear con las plantillas de vivir "en Re #.
  • Añadir Procedimiento - Slick y rápida manera de crear más de la caldera de la placa de código para procs / func.
  • Agregar controlador de errores - Este fue un regalo de los cielos. Ser capaz de con una caída simple pulsación de tecla en el código de control de errores en cualquier sub / función. El manejo de errores es horrible en VB / VBA por lo que esta importante ayuda en la reducción del dolor.
  • Añadir encabezado Módulo y Añadir encabezado de procedimiento - Es como tener GhostDoc . Adición de comentarios es muy importante en el código heredado.
  • Ordenar Procedimientos -Ayuda a organizar el código. Es equivalente a Re # 's' Estructura del archivo de pop-ups 'que yo uso todo el tiempo por las mismas razones: arrastrar y soltar el código de cómo mejor le parezca. 
  • Portapapeles Privado - Esto puede ser importante en el código heredado y en un idioma en el que se queda con un montón de cortar y pegar. En realidad, mejor que la versión Re # 's, porque en realidad se puede controlar lo que se almacena en el mismo y puede mantener durante tanto tiempo como desee dentro de la duración de la sesión. 
  • Revisar el código fuente - una versión muy limitada de análisis de código en Re #. Sólo le indica si una variable, procedimiento constante, no está siendo utilizado. Pero bueno, sin embargo para limpiar el código y deshacerse de costra.
Las siguientes características son interesantes, pero menos utilizada día a día:
  • Generar documentación XML - produce una lectura muy agradable doc xml sobre el código XML comparable a la salida de CHM en VS
  • Estadísticas - Usted puede ver cómo sus líneas de código se distribuye en su base de código.
La única cosa que me gustaría que en mi humilde opinión MZTools tenía que considero que es una de las dos técnicas de refactorización más importantes es " Extraer método "(" Cambiar el nombre de Método 'es el otro). Si tuviera que sería bastante la herramienta de refactorización de roca sólida para VBA. Sin embargo, al igual que MZTool Re # en Visual Studio me ha dado el control sobre mi código en lugar del código de control de mí.

Pruebas unitarias

Ser un profesional dedicado de Test Driven Development (TDD), esto era importante para mí hacerlo en un nivel de lote. Después de ver dos opciones me decidí por VBLiteUnit porque es extremadamente ligero y el tiempo de aceleración de aprendizaje es corto, especialmente si usted está familiarizado con alguno de los otros marcos xUnit (que es exactamente lo que el autor tiene la intención en su creación por lo tanto, la palabra "Lite "en su nombre. Mi creencia es que el autor podría haber pensado que la existente allí, VBAUnit , era demasiado voluminosos y difíciles de utilizar y mantener. Sin duda una forma mucho más "pragmático" y "ágil" en su solución.)

El autor decidió utilizar 'Select Case' la construcción de VB (piense 'Switch'), con cada etapa de su "caso" la definición de una prueba individual. Sorprendentemente funciona muy bien (y ventaja una  añadida es que las descripciones de prueba puede ser más descriptivas y naturales en el tono porque es una cadena de texto. 

Para poner en práctica mis nuevos cambios, como se esperaba, yo tenía que hacer algo de refactorización del código que requería tocarlo.En general, esto dio lugar a nuevas clases comprobables pero no tenía TDD con VBLiteUnit (y MZTools) para liderar el camino.

En suma, fue muy gratificante ser capaz de hacer realidad TDD en Access / VBA. Me dio la misma sensación que tengo al hacer TDD en C #. La plataforma por un momento se sintió mucho más real, como el desarrollo de software de lo que nunca antes había tenido.

Resultados

Algunas lecciones se aprendieron por supuesto ("evolucionar o morir"). Si usted no tiene opciones, recursos, etc en una situación sin importar lo "trivial", entonces usted todavía atacar el problema al 100%. ¿Por qué? Debido a que no solo se puede aplicar y transferir conocimientos y técnicas a otra área de desarrollo de software, sino también que en realidad podría aprender algunas cosas nuevas que a su vez puede utilizar más tarde. Por ejemplo,
  • Empecé a utilizar la ventana Inmediato mucho más ahora en Visual Studio.
  • Empecé a usar las características de Re # que no habían usado o despedidos antes (como las plantillas en vivo, copia del portapapeles, etc)
  • Los patrones de diseño todavía se puede utilizar incluso con lo que algunos consideran una "rudimentaria" lenguaje. Por ejemplo, yo era realmente capaz de poner en práctica una variante del modelo de repositorio (DDD ala Eric Evans) que hidrata un objeto de dominio y hacer que funcione. Por tanto, si a comprender los patrones de diseño y cómo usarlos, entonces no importa qué lenguaje orientado a objetos que está utilizando.
Sin embargo, puedo ver por qué los desarrolladores de VB no saben programación orientada a objetos. Una buena razón es que VB carece de algunas características clave de un lenguaje de programación orientada a objetos. El mayor de ellos, en mi opinión es que no es compatible con la herencia de implementación . Eso fue frustrante porque yo estaba tratando de utilizar una técnica que las plumas de Michael se describe en su libro de trabajo efectiva con el código heredado , para probar el código heredado. Esto implica la creación de una costura en el código que hereda y luego reemplazar una dependencia externa. Por desgracia, VB simplemente hace cumplir el contrato de la interfaz, pero no lleva el código de implementación de la clase base a sus seres derivados.

Sin embargo, el uso de VBA con VBUnitLite y MZTools había hecho llegar a ser mucho más gratificante y, sí, puedo incluso decir en voz alta, "divertida" la experiencia de lo que esperaba. La principal razón más allá de la más obvia, tales como hacer TDD era que yo estaba haciendo tanto TSQL justo antes de que se fue como ser transportados fuera de la edad de piedra. El lenguaje TSQL y el IDE de Microsoft para él (SQL Server Management Studio MGT) fue tan frustrante para el uso que trabajar de nuevo en un lenguaje de programación diseñado para aplicaciones, incluso como "menor / juguete" y con el estigma tanto como Access VBA era como un soplo de fresca el aire y muy estimulante (Fue como dar una cucharada de agua a una persona con mucha sed).

TSQL era y sigue siendo una lucha, incluso con TSQLUnit . Tiene limitaciones tanto en lo que respecta a la creación de lógica de flujo, código reutilizable, y la capacidad de prueba. (Por supuesto que es un organismo especializado de DSL y destinados a la manipulación de los datos y su estructura de almacenamiento, pero me siento como que el lenguaje SQL en realidad no ha evolucionado mucho en los impares de 30 años de existencia. En las zonas que ha cambiado terminó copiando otros no -SQL idiomas así que cuál es el punto? Tal vez es hora de que una lengua mejor reemplazo (s)?) En el futuro, cualquier desarrollador de aplicaciones que me encuentro de nuevo que dice "sprocs son el camino a seguir", obtendrá un mayor rapapolvo y tal vez.

TSQL es tan doloroso en su forma actual que, créanlo o no, prefiero estar trabajando en VBA que en TSQL si aquellos eran mis únicas opciones! Sé que suena loco y sorprendente, pero eso es lo mucho que preferiría no tener que hacer el desarrollo de bases de datos y hacer frente a T-SQL. Voy a dejar a la gente que realmente lo disfruta. Pero, lamentablemente, es la mayor parte de mi trabajo en estos días. (La única cosa que me gusta de él es su compatibilidad con el idioma para "SQL dinámico", pero eso no es suficiente una motivación para mí.)

¿Quién sabe? Pasé de C # -> SQL -> VBA -> SQL en los últimos seis meses. Si hubiera ido de C # -> VBA probablemente tendría una opinión diferente y la experiencia. Es difícil de decir en retrospectiva.

No te preocupes, todavía lo hago en C # y lo han estado haciendo durante los últimos seis meses en paralelo en proyectos paralelos y los procesos de apoyo en el trabajo. Por desgracia, he vuelto a hacer TSQL para los próximos meses. Aargh!

Consideraciones finales

¿Cuál fue el punto de todo esto que no sea para despotricar en alrededor de un idioma a nadie le importa si usted se considera un "grave" programador? Pues bien, al igual que VB6, Microsoft planea retirarse de VBA y, posiblemente, lo que permite aplicaciones de Office con el apoyo de idioma any.NET incluyendo C #! Por lo tanto, las herramientas mencionadas anteriormente están "muertos" en el sentido de un desarrollo nuevo se va hacer en ellos, especialmente de que sus respectivos autores han parecía haber pasado de hacer las nuevas versiones.

En mi humilde opinión, creo que lo que Microsoft realmente debería hacer es permitir que los lenguajes dinámicos apoyen a sus aplicaciones de Office. Ahí es donde los lenguajes dinámicos (por ejemplo Ruby, Python, Boo, etc) parecen ser una forma natural y obvia de la naturaleza de ese trabajo. Imagínese que usted puede escribir código rápidamente con las siempre cambiantes requisitos y no tiene que realizar el avance rápido (en comparación con las lenguas estático de tipos.) Parece una "obviedad". (Tal vez en el futuro lejano, no muy lejano, los usuarios de energía, incluso podría estar escribiendo MS Excel o macros de Word en el F #? Imagínense eso!)

Publicado por Ray Vega  

No hay comentarios:

Publicar un comentario en la entrada