¿Son malos los generadores de código?

StackOverflow https://stackoverflow.com/questions/202871

Pregunta

Utilizo MyGeneration junto con nHibernate para crear los objetos básicos POCO y los archivos de mapeo XML. He escuchado a algunas personas decir que piensan que los generadores de código no son una buena idea. ¿Cuál es el mejor pensamiento actual? ¿Es solo que la generación de código es mala cuando genera miles de líneas de código no comprensible?

¿Fue útil?

Solución

El código generado por un generador de código no debe utilizarse (como una generalización) en una situación en la que posteriormente sea editado por intervención humana. Algunos sistemas, como los asistentes de varias encarnaciones de Visual C ++, generaron código que se esperaba que el programador editara a mano. Esto no era popular ya que requería que los desarrolladores separaran el código generado, lo entendieran y realizaran modificaciones. También significaba que el proceso de generación era de una sola vez.

El código generado debe vivir en archivos separados de otro código en el sistema y solo debe generarse desde el generador. El código del código generado debe estar claramente marcado como tal para indicar que las personas no deben modificarlo. He tenido la oportunidad de hacer bastantes sistemas de generación de código de un tipo u otro y Todos del código generado de esta manera tiene algo como esto en el preámbulo: 

-- =============================================================
-- === Foobar Module ===========================================
-- =============================================================
--
--         === THIS IS GENERATED CODE.  DO NOT EDIT. ===
--
-- =============================================================

Generación de código en acción es un buen libro sobre el tema.

Otros consejos

Los generadores de código son geniales, el código incorrecto es malo.

La mayoría de las otras respuestas en esta página están en la línea de " No, porque a menudo el código generado no es muy bueno. "

Esta es una respuesta pobre porque:

1) Los generadores son herramientas como cualquier otra cosa; si los usa incorrectamente, no culpe a la herramienta.

2) Los desarrolladores tienden a enorgullecerse de su capacidad para escribir un gran código una vez, pero no utiliza generadores de código para proyectos únicos.

Utilizamos un sistema de generación de código para la persistencia en todos nuestros proyectos Java y tenemos miles de clases generadas en producción.

Como gerente, los amo porque:

1) Fiabilidad: no hay errores significativos restantes en ese código. Ha sido tan exhaustivamente probado y refinado a lo largo de los años que cuando se depura, nunca me preocupo por la capa de persistencia.

2) Estandarización: cada código de desarrollador es idéntico a este respecto, por lo que hay mucho menos que un chico aprenda al elegir un nuevo proyecto de un compañero de trabajo.

3) Evolución: si encontramos una mejor manera de hacer las cosas, podemos actualizar las plantillas y actualizar miles de clases de forma rápida y consistente.

4) Revolución: si cambiamos a un sistema de persistencia diferente en el futuro, el hecho de que cada clase persistente tenga una API exactamente idéntica hace que mi trabajo sea mucho más fácil.

5) Productividad: son solo unos pocos clics para construir un sistema de objetos persistente a partir de metadatos; esto ahorra miles de aburridas horas de desarrollador.

La generación de código es como usar un compilador: en un caso individual, es posible que pueda escribir un lenguaje ensamblador mejor optimizado, pero en un gran número de proyectos preferiría que el compilador lo haga por usted, ¿no?

Empleamos un truco simple para garantizar que las clases siempre puedan regenerarse sin perder personalizaciones: cada clase generada es abstracta. Luego, el desarrollador lo amplía con una clase concreta, agrega la lógica comercial personalizada y anula cualquier método de clase base que quiera diferir del estándar. Si hay un cambio en los metadatos, puede regenerar la clase abstracta en cualquier momento, y si el nuevo modelo rompe su clase concreta, el compilador se lo hará saber.

El mayor problema que he tenido con los generadores de código es durante el mantenimiento. Si modifica el código generado y luego realiza un cambio en su esquema o plantilla e intenta regenerar, puede tener problemas.

Un problema es que si la herramienta no le permite proteger los cambios que ha realizado en el código modificado, sus cambios se sobrescribirán.

Otro problema que he visto, particularmente con los generadores de código en RSA para servicios web, si cambia demasiado el código generado, el generador se quejará de que no hay coincidencia y se negará a regenerar el código. Esto puede suceder para algo tan simple como cambiar el tipo de una variable. Luego está atascado generando el código a un proyecto diferente y fusionando los resultados nuevamente en su código original.

Los generadores de código pueden ser una bendición para la productividad, pero hay algunas cosas que debe buscar:

Le permite trabajar de la manera que desee.

Si tiene que doblar su código no generado para que se ajuste al código generado, entonces probablemente debería elegir un enfoque diferente.

Ejecutar como parte de su construcción habitual.

La salida debe generarse en un directorio intermedio y no debe registrarse en el control de origen. Sin embargo, la entrada debe registrarse en el control de origen.

Sin instalación

Idealmente, también debe registrar la herramienta en el control de origen. Hacer que la gente instale cosas al preparar una nueva máquina de construcción es una mala noticia. Por ejemplo, si se bifurca, desea poder versionar las herramientas con el código.

Si es necesario, cree un solo script que tome una máquina limpia con una copia del árbol de origen y configure la máquina según sea necesario. Totalmente automatizado, por favor.

Sin salida de edición

No debería tener que editar la salida. Si el resultado no es lo suficientemente útil como está, entonces la herramienta no está funcionando para usted.

Además, la salida debe indicar claramente que es un archivo generado & amp; no debe ser editado

Salida legible

La salida debe escribirse & amp; bien formateado Desea poder abrir la salida & Amp; léelo sin muchos problemas.

#line

Muchos idiomas admiten algo como una directiva <=>, que le permite asignar el contenido de la salida a la entrada, por ejemplo, al generar mensajes de error del compilador o al ingresar al depurador. Esto puede ser útil, pero también puede ser molesto a menos que se haga realmente bien, por lo que no es un requisito.

Mi postura es que los generadores de código no son malos, pero MUCHOS usos de ellos lo son.

Si está utilizando un generador de código para ahorrar tiempo que escribe un buen código, entonces excelente, pero a menudo no está optimizado o agrega una gran cantidad de sobrecarga, en esos casos creo que es malo.

La generación de código puede causarle cierta molestia si desea mezclar el comportamiento en sus clases. Una alternativa igualmente productiva podría ser atributos / anotaciones y reflexión en tiempo de ejecución.

Los compiladores son generadores de código, por lo que no son intrínsecamente malos a menos que solo le guste programar en código máquina sin procesar.

Sin embargo, creo que los generadores de código siempre deben encapsular completamente el código generado. Es decir. no debería nunca modificar el código generado a mano, cualquier cambio debe realizarse modificando la entrada al generador y regenerando el código.

Si es un generador de código cobol mainframe que Fran Tarkenton está tratando de venderte, ¡entonces sí!

He escrito algunos generadores de código antes, y para ser honesto, ¡me salvaron el trasero más de una vez!

Una vez que tenga un objeto claramente definido - colección - diseño de control de usuario, puede usar un generador de código para construir lo básico para usted, permitiendo que su tiempo como desarrollador se use de manera más efectiva en la construcción de cosas complejas, después de todo, ¿Quién realmente quiere escribir más de 300 declaraciones de propiedad pública e instancias variables? Prefiero quedarme atrapado en la lógica empresarial que en todas las tareas repetitivas sin sentido.

El error que muchas personas cometen al usar la generación de código es editar el código generado. Si tiene en cuenta que si siente que necesita editar el código, en realidad necesita editar la herramienta de generación de código, es una bendición para la productividad. Si constantemente está luchando contra el código que se genera, terminará costando productividad.

Los mejores generadores de código que he encontrado son aquellos que le permiten editar las plantillas que generan el código. Realmente me gusta Codesmith por este motivo, porque está basado en plantillas y las plantillas son fácilmente editables. Cuando descubres que hay una deficiencia en el código que se genera, solo editas la plantilla y regeneras tu código y eres siempre bueno después de eso.

La otra cosa que he encontrado es que muchos generadores de código no son muy fáciles de usar con un sistema de control de fuente. La forma en que hemos solucionado esto es verificando las plantillas en lugar del código y lo único que verificamos en el control de origen que se genera es una versión compilada del código generado (archivos DLL, principalmente ) Esto le ahorra mucha pena porque solo tiene que registrar algunas DLL en lugar de posiblemente cientos de archivos generados.

Nuestro proyecto actual hace un uso intensivo de un generador de código. Eso significa que he visto tanto el & Quot; obvio & Quot; Beneficios de generar código por primera vez: sin error de codificador, sin errores tipográficos, mejor adherencia a un estilo de codificación estándar y, después de unos meses en modo de mantenimiento, las desventajas inesperadas. Nuestro generador de código, de hecho, mejoró inicialmente la calidad de nuestra base de código. Nos aseguramos de que estuviera completamente automatizado e integrado con nuestras compilaciones automatizadas. Sin embargo, diría que:

(1) Un generador de código puede ser una muleta. Tenemos varios bloques masivos y feos de código difícil de mantener en nuestro sistema ahora, porque en un momento en el pasado era más fácil agregar veinte nuevas clases a nuestro archivo XML de generación de código, que hacer un análisis y clase adecuados refactorización.

(2) Las excepciones a la regla te matan. Usamos el generador de código para crear varios cientos de clases Screen y Business Object. Inicialmente, aplicamos un estándar sobre qué métodos podrían aparecer en una clase, pero como todos los estándares, comenzamos a hacer excepciones. Ahora, nuestro archivo XML de generación de código es un monstruo masivo, lleno de fragmentos de código de casos especiales que se insertan en clases seleccionadas. Es casi imposible analizar o comprender.

(3) Dado que gran parte de nuestro código se genera, utilizando valores de una base de datos, es difícil para los desarrolladores mantener una base de código consistente en sus estaciones de trabajo individuales (ya que puede haber múltiples versiones de la base de datos). La depuración y el rastreo a través del software es mucho más difícil, y los novatos en el equipo tardan mucho más en descubrir el & "; Flujo &"; del código, debido a la abstracción adicional y las relaciones implícitas entre clases. Los IDE no pueden recoger las relaciones entre dos clases que se comunican a través de una clase generada por código.

Eso es probablemente suficiente por ahora. Creo que los generadores de código son excelentes como parte del kit de herramientas individual de un desarrollador; Un conjunto de scripts que escriben su código repetitivo hacen que comenzar un proyecto sea mucho más fácil. Pero los Generadores de Código no hacen que los problemas de mantenimiento desaparezcan.

En ciertos (no muchos) casos son útiles. Por ejemplo, si desea generar clases basadas en datos de tipo de búsqueda en las tablas de la base de datos.

La generación de código es mala cuando dificulta la programación (IE, código mal generado o una pesadilla de mantenimiento), pero son buenos cuando hacen que la programación sea más eficiente.

Probablemente no siempre generan un código óptimo, pero dependiendo de su necesidad, puede decidir que las horas de trabajo guardadas del desarrollador compensan algunos problemas menores.

Todo lo dicho, mi mayor queja con los generadores de código ORM es que el mantenimiento del código generado puede ser un PITA si el esquema cambia.

Los generadores de código no son malos, pero a veces se usan en situaciones en las que existe otra solución (es decir, crear instancias de un millón de objetos cuando una matriz de objetos hubiera sido más adecuada y lograda en unas pocas líneas de código).

La otra situación es cuando se usan incorrectamente o están mal codificados. Demasiadas personas rechazan los generadores de código porque han tenido malas experiencias debido a errores o su malentendido sobre cómo configurarlo correctamente.

Pero en sí mismos, los generadores de código no son malos.

-Adam

Son como cualquier otra herramienta. Algunos dan mejores resultados que otros, pero depende del usuario saber cuándo usarlos o no. Un martillo es una herramienta terrible si intenta atornillar un tornillo.

Este es uno de esos temas altamente polémicos. Personalmente, creo que los generadores de código son realmente malos debido al código basura no optimizado que la mayoría saca.

Sin embargo, la pregunta es realmente una que solo tú puedes responder. En muchas organizaciones, el tiempo de desarrollo es más importante que la velocidad de ejecución del proyecto o incluso la mantenibilidad.

Usamos generadores de código para generar clases de entidad de datos, objetos de base de datos (como disparadores, procesos almacenados), proxies de servicio, etc. Pero, no debe usarlo demasiado en la medida en que la mantenibilidad es una molestia. También surgen algunos problemas si desea regenerarlos.

Herramientas como Visual Studio, Codesmith tienen sus propias plantillas para la mayoría de las tareas comunes y facilitan este proceso. Pero, es fácil de implementar por su cuenta.

Realmente puede convertirse en un problema de mantenimiento cuando tiene que volver y no puede entender lo que está sucediendo en el código. Por lo tanto, muchas veces debe sopesar la importancia de realizar el proyecto rápidamente en comparación con la facilidad de mantenimiento

mantenibilidad < > proceso de codificación fácil o rápido

Uso My Generation with Entity Spaces y no tengo ningún problema con él. Si tengo un cambio de esquema, simplemente regenero las clases y todo funciona bien.

Sirven como una muleta que puede deshabilitar su capacidad de mantener el programa a largo plazo.

Los primeros compiladores de C ++ fueron generadores de código que escupieron código C (CFront).

No estoy seguro de si este es un argumento a favor o en contra de los generadores de código.

Creo que Mitchel lo golpeó en la cabeza. La generación de código tiene su lugar. ¡Hay algunas circunstancias en las que es más efectivo que la computadora haga el trabajo por usted! Puede darle la libertad de cambiar de opinión acerca de la implementación de un componente en particular cuando el costo de tiempo para realizar cambios en el código es pequeño. Por supuesto, todavía es importante entender la salida del generador de código, pero no siempre es así. Teníamos un ejemplo de un proyecto que acabamos de terminar donde varias aplicaciones de C ++ necesitaban comunicarse con una aplicación de C # a través de canalizaciones con nombre. Fue mejor para nosotros usar archivos pequeños y simples que definían los mensajes y tenían todas las clases y códigos generados para cada lado de la transacción. Cuando un programador estaba trabajando en el problema X, lo último que necesitaban era preocuparse por los detalles de implementación de los mensajes y el inevitable golpe de caché que conllevaría.

Esta es una pregunta de flujo de trabajo. ASP.NET es un generador de código. El motor de análisis XAML en realidad genera C # antes de que se convierta a MSIL. Cuando un generador de código se convierte en un producto externo como CodeSmith que está aislado de su flujo de trabajo de desarrollo, se debe tener especial cuidado para mantener su proyecto sincronizado. Por ejemplo, si el código generado es una salida ORM y realiza un cambio en el esquema de la base de datos, deberá abandonar completamente el generador de código o bien aprovechar la capacidad de C # para trabajar con clases parciales (que le permiten agregar miembros y funcionalidad a una clase existente sin heredarla).

Personalmente no me gusta la naturaleza aislada / Alt-Tab de los flujos de trabajo del generador; Si el generador de código no es parte de mi IDE, siento que es un error. Algunos generadores de código, como Entity Spaces 2009 (aún no lanzado), están más integrados que las generaciones anteriores de generadores.

Creo que la panacea para el propósito de los generadores de código se puede disfrutar en las rutinas de precompilación. C # y otros lenguajes .NET carecen de esto, aunque ASP.NET lo disfruta y por eso, por ejemplo, SubSonic funciona tan bien para ASP.NET pero no mucho más. SubSonic genera código C # en tiempo de compilación justo antes de que comience la compilación ASP.NET normal.

Pídale a su proveedor de herramientas (es decir, Microsoft) que respalde las rutinas de precompilación más a fondo, de modo que los generadores de código se puedan integrar en el flujo de trabajo de sus soluciones utilizando metadatos, en lugar de administrarse manualmente como archivos de código emitidos externamente que deben mantenerse en aislamiento.

Jon

La mejor aplicación de un generador de código es cuando todo el proyecto es un modelo, y todo el código fuente del proyecto se genera a partir de ese modelo. No estoy hablando de UML y basura relacionada. En este caso, el modelo del proyecto también contiene código personalizado.

Entonces lo único que los desarrolladores tienen que preocuparse es el modelo. Un simple cambio arquitectónico puede resultar en la modificación instantánea de miles de líneas de código fuente. Pero todo permanece sincronizado.

Este es, en mi humilde opinión, el mejor enfoque. ¿Suena utópico? Al menos sé que no lo es;) El futuro cercano lo dirá.

En un proyecto reciente construimos nuestro propio generador de código. Generamos todas las cosas de la base de datos y todo el código base para nuestras clases de vista y controlador de vista. Aunque el generador tardó varios meses en construirse (principalmente porque era la primera vez que lo hacíamos, y tuvimos un par de inicios falsos), se pagó por sí mismo la primera vez que lo ejecutamos y generó el marco básico para toda la aplicación en Unos diez minutos. Todo esto estaba en Java, pero Ruby es un excelente lenguaje de escritura de código, particularmente para proyectos pequeños de tipo único. Lo mejor fue la consistencia del código y la organización del proyecto. Además, tienes que pensar en el marco básico con anticipación, lo que siempre es bueno.

Los generadores de código son geniales asumiendo que es un buen generador de código. Especialmente trabajando c ++ / java que es muy detallado.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top