¿Creas tus propios generadores de código?
https://stackoverflow.com/questions/113286
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
El programador pragmático aboga por el uso de generadores de código.¿Creas generadores de código en tus proyectos?Si es así, ¿para qué los usas?
Solución
Los generadores de código, si se usan ampliamente sin la argumentación correcta, hacen que el código sea menos comprensible y disminuyen la capacidad de mantenimiento (por cierto, lo mismo ocurre con el SQL dinámico).Personalmente, lo estoy usando con algunas herramientas ORM, porque su uso aquí es en su mayoría obvio y, a veces, para cosas como algoritmos de búsqueda y análisis y analizadores gramaticales que últimamente no están diseñados para ser mantenidos "a mano".Salud.
Otros consejos
En "Pragmatic Programmer", Hunt y Thomas distinguen entre generadores de código pasivos y activos.
Los generadores pasivos se ejecutan una vez, después de lo cual se edita el resultado.
Los generadores activos se ejecutan con la frecuencia deseada y nunca debes editar el resultado porque será reemplazado.
En mi opinión, estos últimos son mucho más valiosos porque se acercan al principio SECO (no te repitas).
Si la información de entrada a su programa se puede dividir en dos partes, la parte que rara vez cambia (A) (como metadatos o DSL) y la parte que es diferente cada vez que se ejecuta el programa (B) (la entrada en vivo) , puede escribir un programa generador que solo tome A como entrada y escribir un programa ad-hoc que solo tome B como entrada.(Otro nombre para esto es evaluación parcial).
El programa generador es más simple porque solo tiene que pasar por la entrada A, no por A y B.Además, no tiene que ser rápido porque no se ejecuta con frecuencia y no tiene por qué preocuparse por las pérdidas de memoria.
El programa ad-hoc es más rápido porque no tiene que leer entradas que casi siempre son las mismas (A).Es más sencillo porque sólo tiene que tomar decisiones sobre la entrada B, no sobre A y B.
Es una buena idea que el programa ad-hoc generado sea bastante legible, para que puedas encontrar más fácilmente cualquier error que contenga.Una vez que elimine los errores del generador, desaparecerán para siempre.
En un proyecto en el que trabajé, un equipo diseñó una aplicación de base de datos compleja con una especificación de diseño de dos pulgadas de espesor y un largo cronograma de implementación, plagado de preocupaciones sobre el rendimiento.Al escribir un generador de código, dos personas hicieron el trabajo en tres meses, y los listados de código fuente (en C) tenían aproximadamente media pulgada de espesor, y el código generado fue tan rápido que no fue un problema.El programa ad hoc se regeneraba semanalmente, a un costo insignificante.
Entonces generación de código activo, cuando puedes usarlo, es beneficioso para todos.Y creo que no es casualidad que esto sea exactamente lo que hacen los compiladores.
En el diseño de hardware, es una práctica bastante común hacer esto en varios niveles de la "pila".Por ejemplo, escribí un generador de código para emitir Verilog para varios anchos, topologías y estructuras de motores DMA y conmutadores de barra transversal, porque las construcciones necesarias para expresar esta parametrización aún no estaban maduras en los flujos de herramientas de síntesis y simulación.
También es rutinario emitir modelos lógicos hasta los datos de diseño para cosas muy regulares que pueden expresarse y generarse algorítmicamente, como SRAM, caché y estructuras de archivos de registro.
También pasé bastante tiempo escribiendo, esencialmente, un generador de código que tomaría una descripción XML de todos los registros en un System-on-Chip y emitiría HTML (sí, sí, conozco XSLT, acabo de descubrir que emitting programáticamente para que sea más efectivo en el tiempo), Verilog, SystemVerilog, C, Assembly, etc."vistas" de esos datos para que diferentes equipos (diseño ASIC de front-end y back-end, firmware, documentación, etc.) las utilicen (y las mantengan consistentes en virtud de esta única "base de código" XML).¿Eso cuenta?
A la gente también le gusta escribir generadores de código, por ejemplo.tomar descripciones concisas de cosas muy comunes, como máquinas de estados finitos, y generar mecánicamente un código de lenguaje imperativo más detallado para implementarlas de manera eficiente (por ejemplo,tablas de transición y código transversal).
Usamos generadores de código para generar clases de entidades de datos, objetos de bases de datos (como activadores, procesos almacenados), servidores proxy, etc.En cualquier lugar donde vea mucho código repetitivo siguiendo un patrón y mucho trabajo manual involucrado, los generadores de código pueden ayudar.Pero no debe usarlo demasiado hasta el punto de que la mantenibilidad sea una molestia.También surgen algunos problemas si desea regenerarlos.
Herramientas como Visual Studio y Codesmith tienen sus propias plantillas para la mayoría de las tareas comunes y facilitan este proceso.Pero es fácil implementarlo por su cuenta.
A menudo resulta útil crear un generador de código que genere código a partir de una especificación, normalmente uno que tenga reglas tabulares regulares.Reduce la posibilidad de introducir un error por error tipográfico u omisión.
Sí, desarrollé mi propio generador de código para el diámetro del protocolo AAA (RFC 3588).Podría generar estructuras y API para mensajes de diámetro leídos desde un archivo XML que describiera la gramática de la aplicación de diámetro.
Eso redujo en gran medida el tiempo para desarrollar una interfaz de diámetro completo (como SH/CX/RO, etc.).
en mi opinión, un buen lenguaje de programación no necesitaría generadores de código porque la introspección y la generación de código en tiempo de ejecución serían parte del lenguaje, por ejemplo.en metaclases de Python y nuevos módulos, etc.
Los generadores de código suelen generar más código inmanejable en el uso a largo plazo.
sin embargo, si es absolutamente imperativo usar un generador de código (lo que uso a veces es Eclipse VE para desarrollo swing), entonces asegúrese de saber qué código se está generando.Créame, no querrá incluir código en su aplicación con el que no esté familiarizado.
Escribir un generador propio para el proyecto no es eficiente.En su lugar, utilice un generador como T4, CodeSmith y Zontroy.
T4 es más complejo y es necesario conocer un lenguaje de programación .Net.Debe escribir su plantilla línea por línea y debe completar las operaciones relacionales de datos por su cuenta.Puedes usarlo sobre Visual Studio.
CodeSmith es una herramienta funcional y hay muchas plantillas listas para usar.Está basado en T4 y escribir su propia plantilla lleva demasiado tiempo como en T4.Hay una versión de prueba y una comercial.
Zontroy es una nueva herramienta con una interfaz de usuario fácil de usar.Tiene su propio lenguaje de plantilla y es fácil de aprender.Existe un mercado de plantillas en línea y se está desarrollando.Incluso usted puede entregar plantillas y venderlas en línea en el mercado.Tiene una versión gratuita y otra comercial.Incluso la versión gratuita es suficiente para completar un proyecto de mediana escala.
Puede que existan muchos generadores de código, sin embargo, siempre creo el mío propio para que el código sea más comprensible y se adapte a los marcos y pautas que utilizamos.
Usamos un generador para todo el código nuevo para ayudar a garantizar que se sigan los estándares de codificación.
Recientemente reemplazamos nuestro generador interno de C++ con Código Smith.Aún tenemos que crear las plantillas para la herramienta, pero parece ideal no tener que mantener la herramienta nosotros mismos.
Mi necesidad más reciente de un generador fue un proyecto que leyera datos del hardware y finalmente los publicara en una interfaz de usuario de "panel".En el medio estaban modelos, propiedades, presentadores, eventos, interfaces, banderas, etc.para varios puntos de datos.Preparé el marco para un par de puntos de datos hasta que estuve satisfecho de que podía vivir con el diseño.Luego, con la ayuda de algunos comentarios cuidadosamente colocados, puse la "generación" en una macro de Visual Studio, modifiqué y limpié la macro, agregué los puntos de datos a una función en la macro para llamar a la generación y me ahorré varias horas tediosas (días). ?) al final.
No subestimes el poder de las macros :)
Ahora también estoy tratando de entender CódigoRush capacidades de personalización para ayudarme con algunos requisitos de generación más locales.Hay cosas poderosas ahí si necesitas tomar decisiones sobre la marcha al generar un bloque de código.
Tengo mi propio generador de código que ejecuto en tablas SQL.Genera los procedimientos SQL para acceder a los datos, la capa de acceso a datos y la lógica de negocio.Ha hecho maravillas al estandarizar mi código y mis convenciones de nomenclatura.Debido a que espera ciertos campos en las tablas de la base de datos (como una columna de identificación y una columna de fecha y hora actualizada), también ha ayudado a estandarizar mi diseño de datos.
¿Cuantos buscas?He creado dos mayores y numerosos menores.El primero de los principales me permitió generar programas de 1500 líneas (más o menos) que tenían un gran parecido familiar pero estaban en sintonía con las diferentes tablas de una base de datos, y hacerlo de forma rápida y confiable.
La desventaja de un generador de código es que si hay un error en el código generado (porque la plantilla contiene un error), entonces hay mucho que arreglar.
Sin embargo, para lenguajes o sistemas en los que hay que realizar una gran cantidad de codificación casi repetitiva, un generador de código (suficientemente bueno) es una bendición (y más una bendición que un "doggle").
Sí, he tenido que mantener algunos.CORBA o algún otro estilo de interfaz de comunicación de objetos es probablemente lo primero en lo que pienso.Tiene definiciones de objetos que le proporciona la interfaz de la que va a hablar, pero aún tiene que crear esos objetos en código.Construir y ejecutar un generador de código es una forma bastante rutinaria de hacerlo.Esto puede convertirse en una compilación bastante larga sólo para soportar algún canal de comunicación heredado, y dado que hay una gran tendencia a poner envoltorios alrededor de CORBA para hacerlo más simple, bueno, las cosas simplemente empeoran.
En general, si tiene una gran cantidad de estructuras, o simplemente estructuras que cambian rápidamente y necesita usar, pero no puede manejar el impacto en el rendimiento de la construcción de objetos a través de metadatos, entonces debe escribir un generador de código.
No puedo pensar en ningún proyecto en el que necesitáramos crear nuestros propios generadores de código desde cero, pero hay varios en los que utilizamos generadores preexistentes.(He usado Antlr y Eclipse Modeling Framework para crear analizadores y modelos en Java para software empresarial). La belleza de usar un generador de código que otra persona ha escrito es que los autores tienden a ser expertos en esa área y han resuelto problemas. que ni siquiera sabía que existía todavía.Esto me ahorra tiempo y frustración.
Entonces, aunque pueda escribir código que resuelva el problema en cuestión, puedo generar el código mucho más rápido y hay muchas posibilidades de que tenga menos errores que cualquier cosa que escriba.
Si no va a escribir el código, ¿se sentirá cómodo con el código generado por otra persona?
¿Es más barato en tiempo y dinero a largo plazo escribir su propio código o generador de código?
Escribí un generador de código que crearía cientos de clases (java) que generarían datos XML de la base de datos de una manera compatible con DTD o esquema.La generación del código generalmente era algo que se hacía una sola vez y luego el código se perfeccionaba con varias reglas comerciales, etc.El resultado fue para un banco bastante pedante.
Los generadores de código son una solución alternativa a las limitaciones del lenguaje de programación.Personalmente prefiero la reflexión en lugar de los generadores de código, pero estoy de acuerdo en que los generadores de código son más flexibles y el código resultante obviamente es más rápido durante el tiempo de ejecución.Espero que las versiones futuras de C# incluyan algún tipo de entorno DSL.
Los únicos generadores de código que utilizo son analizadores de servicios web.Personalmente, me mantengo alejado de los generadores de códigos debido a los problemas de mantenimiento para los nuevos empleados o un equipo separado después del traspaso.
Escribo mis propios generadores de código, principalmente en T-SQL, a los que se llama durante el proceso de construcción.
Según los datos del metamodelo, generan activadores, registros, declaraciones constantes de C#, declaraciones INSERT/UPDATE e información del modelo de datos para verificar si la aplicación se está ejecutando en el esquema de base de datos esperado.
Todavía necesito escribir un generador de formularios para aumentar la productividad, más especificaciones y menos codificación;)
He creado algunos generadores de código.Tenía un generador de código pasivo para procedimientos almacenados de SQL que usaba plantillas.Esto generó el 90% de nuestros procedimientos almacenados.
Desde que hicimos el cambio a Entity Framework, creé un generador de código activo usando T4 (Kit de herramientas de transformación de plantillas de texto) dentro del estudio visual.Lo he usado para crear clases parciales de repositorio básico para nuestras entidades.Funciona muy bien y ahorra mucha codificación.También uso T4 para decorar las clases de entidad con ciertos Atributos.
Utilizo funciones de generación de código proporcionadas por EMF - Marco de modelado de Eclipse.
Los generadores de código son realmente útiles en muchos casos, especialmente cuando se asignan de un formato a otro.He creado generadores de código para IDL a C++, tablas de bases de datos a tipos OO y clasificación de código, solo por nombrar algunos.
Creo que lo que los autores intentan señalar es que si eres desarrollador deberías poder hacer que la computadora funcione para ti.Generar código es sólo una tarea obvia para automatizar.
Una vez trabajé con un tipo que insistía en que haría nuestro mapeo de IDL a C++ manualmente.Al principio del proyecto pudo mantener el ritmo, porque el resto de nosotros estábamos tratando de descubrir qué hacer, pero finalmente se convirtió en un cuello de botella.Hice un generador de código en Perl y luego pudimos hacer su "trabajo" en unos minutos.
Vea nuestro generador de código "universal" basado en transformaciones del programa.
Soy el arquitecto y un implementador clave.Vale la pena señalar que una fracción significativa de este generador se genera utilizando este generador.
En los sistemas integrados, a veces se necesita un gran bloque de datos binarios en la memoria flash.Por ejemplo, tengo uno que toma un archivo de texto que contiene glifos de fuentes de mapa de bits y lo convierte en un par de archivos .cc/.h que declara constantes interesantes (como el primer carácter, el último carácter, el ancho y alto del carácter) y luego los datos reales como un gran static const uint8_t[].
Intentar hacer algo así en C++, de modo que los datos de fuente se generen automáticamente en la compilación sin un primer paso, sería una molestia y probablemente ilegible.Escribir un archivo .o a mano está fuera de discusión.También lo es romper papel cuadriculado, codificar manualmente en binario y escribir todo eso.
En mi humilde opinión, para este tipo de cosas están los generadores de códigos. Nunca olvides que el ordenador trabaja para ti y no al revés.
Por cierto, si usas un generador, siempre siempre siempre incluya algunas líneas como esta tanto al inicio como al final de cada archivo generado:
// This code was automatically generated from Font_foo.txt. DO NOT EDIT THIS FILE.
// If there's a bug, fix the font text file or the generator program, not this file.
nosotros usamos telosys generador de código en nuestros proyectos: http://www.telosys.org/
Lo hemos creado para reducir la duración del desarrollo en tareas recurrentes como pantallas CRUD, documentación, etc...
Para nosotros lo más importante es poder personalizar las plantillas del generador, para poder crear objetivos de nueva generación si es necesario y personalizar las plantillas existentes.Es por eso que también hemos creado un editor de plantillas (para archivos Velocity .vm).Funciona bien para el generador de código Java/Spring/AngularJS y se puede adaptar a otros objetivos (PHP, C#, Python, etc.)
