Argumentando para la generación de código, estoy buscando algunos ejemplos de formas en que aumenta la calidad del código. Para aclarar lo que quiero decir con generación de código, solo puedo hablar sobre un proyecto mío:
Utilizamos archivos XML para describir las relaciones entre entidades en nuestro esquema de base de datos, por lo que nos ayudan a generar nuestro marco ORM y formularios HTML que se pueden usar para agregar, eliminar y modificar entidades.
En mi opinión, aumenta la calidad del código porque se reduce el error humano. Si algo se implementa incorrectamente, se rompe en el modelo, lo cual es bueno porque el error puede aparecer antes, ya que también se rompe más código generado.
Como me pidieron la definición de la calidad del código , déjenme aclarar esto, lo que quise decir es la calidad del software .
Calidad del software : no es un atributo sino muchos, por ejemplo, eficiencia, modificabilidad, legibilidad, corrección, robustez, comprensibilidad, usabilidad, portabilidad, etc., que se afectan entre sí.
fuente
Respuestas:
Los generadores de código no pueden generar un código mejor que la persona que escribió el generador.
Mi experiencia con los generadores de código es que están bien siempre y cuando nunca tenga que editar el código generado . Si puedes aferrarte a esa regla, entonces estás listo para comenzar. Esto significa que puede volver a generar de manera confiable esa parte del sistema con confianza y velocidad, agregando automáticamente más funciones si es necesario. Supongo que eso podría contar para la calidad.
Una vez escuché un argumento para los generadores de código de que un solo programador puede producir tantas y tantas líneas de código por día y con los generadores de código, ¡podrían producir miles de líneas! Obviamente, esa no es la razón por la que estamos usando generadores.
fuente
Yo diría lo contrario : suponiendo que esté escribiendo aplicaciones interesantes, la generación de código disminuye la calidad del código. La naturaleza de la generación de código recompensa marcos muy cortadores de cookies, exagerados y demasiado especificados que se vuelven muy difíciles de manejar sin depender continuamente de la herramienta de generación de código para generar continuamente grupos de código más grandes, más complejos y más feos. Si bien puede ser una buena herramienta, realmente no debería ser la herramienta principal en el cuadro.
fuente
Creo que la generación y la calidad de código automatizadas son algo ortogonales y no necesariamente se correlacionan.
La generación de código es simplemente una forma de resolver una tarea técnica específica. Si resulta en una mayor calidad del código depende mucho de lo que esté haciendo.
Su situación es un buen ejemplo de generación de código que resulta en una mayor calidad del código a través de la detección temprana de posibles errores.
Puedo darle otro ejemplo cuando la generación automática de código disminuye la calidad del código. Está fuera de todo poderoso ASP.NET WebForms. Realiza la generación de código automatizada al traducir una jerarquía de controles de UI en marcado HTML, que es todo menos estable, predecible y manejable.
Para llegar a la conclusión, la generación automática de código puede ayudar a aumentar la calidad del código cuando se usa correctamente.
fuente
La generación de código no afecta la calidad del código , per se, tanto como la consistencia del código .
El código generado será consistente entre instancias de generación. Si el generador está diseñado para emitir código de buena calidad, entonces el código generado será de una calidad consistentemente buena. Sin embargo, si el generador de código emite un código de mala calidad, obtendrás un código constantemente malo.
La generación de código también se puede usar para construir código más rápido . Sin embargo, más rápido no significa mejor ... Simplemente podría significar que obtienes tu código de mala calidad mucho más rápido.
fuente
La generación de código es buena si:
Cuando este es el caso, el código cuya calidad debe tener en cuenta es el código que se ingresa al generador.
Una medida simple de la calidad es, para los cambios típicos en los requisitos, cuánto tiene que hacer la edición manual. Cuanto menos, mejor.
fuente
Aumento de la calidad del código debido a DRY (no se repita).
Las reglas de generación de código se escriben una vez; no están codificados para cada instancia de código generado, y por lo tanto reducen el potencial de error humano al copiar / pegar el contenido con ligeras modificaciones.
fuente
Supongo que te refieres a generadores de código patentados manejados para un uso interno específico, ya que de lo contrario cualquier cosa que no sea código de máquina es un generador de código. Pero aquí tienes:
Creo que es muy discutible que el gráfico de nodo en Blueprints sea más fácil de mantener y mucho menos propenso a errores que el código GLSL / HLSL que genera (y de lo contrario hubiera sido necesario escribirlo a mano).
También es mucho más productivo crear nuevos sombreadores, ya que obtienes una retroalimentación visual en tiempo real de cómo se ve el resultado final a medida que cambias el gráfico. Definitivamente preferiría mantener miles de sombreadores representados con gráficos nodales de esta manera en lugar de código GLSL / HLSL, y en realidad estoy más familiarizado con escribir GLSL / HLSL que con Blueprints. Creo que en realidad es prácticamente imposible causar como un error importante, además de algún error visual menor que probablemente atraparías de inmediato porque el "lenguaje visual" impone restricciones sensibles con un estilo funcional puro que no te permite, por ejemplo, estrellar un sombreador, al menos AFAIK (ciertamente no soy un experto en Blueprints).
Ya ni siquiera hay un "código" para mantener. Simplemente coloca nodos dentro de un gráfico y dibuja enlaces entre ellos y, voila, genera un código de sombreador para usted. Quien mantiene estas cosas y dice: " Sabes, mi vida sería mucho más fácil y tendría mucho más tiempo libre si solo estuviera escrito en código GLSL en lugar de usar Blueprints " . Probablemente nunca.
Dicho esto, me he encontrado con mi parte de generadores de código patentados que hicieron la vida más difícil, haciéndome aprender este estúpido metalenguaje que tiene beneficios muy limitados, si los hay, sobre escribir código en el lenguaje del código que generó. Para mí, una señal reveladora de generación de código que es una mierda es algo que hace poco más que reducir una pequeña cantidad de repetitivo y en realidad no reduce, por ejemplo, la posibilidad de errores. Sabes que es especialmente malo si en realidad introduce nuevas formas de causar errores que el idioma original no tenía. Pero hay casos para la generación de código, como el anterior, en los que el aumento de la productividad es tan masivo, lo que hace que las cosas meticulosas que cuestan un tiempo enorme ahora cuestan centavos, que nadie lo usará y luego mirará hacia atrás.
Para mí, hay un argumento más legítimo para el desarrollo patentado de Blueprints entre el equipo de Epic que muchos lenguajes de programación superfluos creados para el público en general que apenas aportan nada nuevo a la mesa.
fuente
Yo diría que en su caso podría aumentar un poco la calidad, pero reduce mucho el tiempo de desarrollo. A veces, el código generado es escamoso, incómodo o simplemente malo. En esos casos, el código generado puede disminuir la calidad y agregar más tiempo de prueba / fijación / prueba de regresión al proyecto. Y algunas tareas son demasiado complejas para ser fácilmente generadas: el generador se convierte en un sistema completamente separado (posiblemente más grande y más complejo que el proyecto principal) en sí mismo.
Los generadores de códigos están bien, ¡pero ten cuidado con ellos!
fuente
Solía trabajar en una tienda que dependía mucho de la generación de código. En mi opinión, el código para el proyecto era muy uniforme. Y en ese sentido, la calidad estaba bien.
Sin embargo, cuando ya no se te permite escribir código personalizado porque todo tiene que pasar por el generador, creo que pierdes algo de la ventaja de ser un programador.
Así que creo que este es un tema de espada de doble filo con seguridad. Sí, los generadores son geniales porque reducen los errores y aumentan los estándares de código, sin embargo, también hacen que "algunos" de los programadores sean tontos, porque dependen de los generadores en lugar de tener que ensuciarse las manos.
Solo mis 2 centavos.
fuente
x=someValue ^ 0xFF ^ 0xFF ^ 0xFF ^ 0xFF;y codificarlo con cuatro instrucciones literales XOR. Si el medio de almacenamiento de código solo puede escribir bytes en blanco (0xFF), la construcción anterior permitirá cuatro cambios arbitrarios en el valor. Incluso si uno reescribiera la expresión comox=someValue; x = x ^ 0xFF ^ 0xFF ^ 0xFF ^ 0xFF;y el compilador evaluó todos los xors en tiempo de ejecución, aún podría usar un "complemento todos los bits" ...Además de la respuesta de Martin, agregaría que la generación de código SQL es muy buena cuando trabaja registro por registro (seleccione * de tab1 donde tab1.pkcolumn =: parámetro, actualice tab1 set [cualquier número de columnas] donde tab1.pkcolumn =: parámetro, etc.). Y su ORM brillará en ese escenario, porque el SQL que debe generarse es realmente repetitivo.
Mis principales preocupaciones son las metaconsultas: consultas sobre las propiedades del objeto que el ORM traduce a SQL utilizando cualquier algoritmo. Metaconsultas muy similares pueden generar SQL completamente diferente, y no tienen garantía de que este SQL generado sea performatico.
Un lenguaje de metaconsulta que se traduce a otro lenguaje (SQL) que se traduce en un plan de consulta para ejecutar efectivamente la recopilación de datos. Y el resultado generado debe ser objetos, por lo que el ORM debe instanciar los objetos afectados, de modo que pueda desencadenar otra lluvia de consultas para llenar los atributos de los objetos no traídos por la propia metaconsulta ...
fuente
Estoy totalmente de acuerdo con aquellos que dicen que la generación de código está bien siempre y cuando nunca tenga que editar (preferiblemente, nunca tenga que mirar) el código generado.
Si podemos aceptar que el código generado es aproximadamente el mismo número de líneas que el escrito a mano, y si podemos decir que está libre de errores, entonces el número de líneas que podrían contener errores ha disminuido. Ergo, la calidad del código debería haber aumentado.
Anexo: por supuesto, otros factores, como el tiempo de ejecución, pueden desempeñar un papel.
Personalmente, he escrito bastantes generadores de código, pero nunca como un enfoque inicial.
Siempre ha sido cuando noté un patrón repetitivo en el código existente, por lo que mi generador toma algo de código existente al agregar código nuevo, pero similar, y parametriza algunas partes variables del mismo.
Hasta ese punto, mi código generado es casi idéntico al código escrito a mano existente (excepto que tiende a presentarse mejor visualmente y es más uniforme, lo que creo que ayuda a la legibilidad, si es que alguna vez hay que mirarlo).
Por cierto, abogo por insertar comentarios de apertura / cierre que indiquen que se generó el código, incluidos los detalles de la herramienta y su mantenedor.
fuente