Archivo del sitio
10 Ventajas de la Generación de Código
Vayamos al grano. He aquí la lista:
- Calidad SW: En todos los aspectos: rendimiento, fiabilidad, seguridad, etc.
- Estandarización: no sólo en el código fuente: en la interfaz de usuario, en las estructuras de base de datos, etc.
- Centralización: políticas globales tales como el manejo de errores, la gestión de excepciones, el formato de visualización de datos, las validaciones de datos, comprobar los permisos, etc. están centralizados en el generador. Este tipo de políticas son también conocidos como funcionalidades transversales y es un tema abordado por la Programación Orientada a Aspectos (AOP en inglés) en la programación tradicional. La centralización evita este problema.
- Refactorización: relacionado con el beneficio anterior, la refactorización de código es fácil y segura.
- Productividad: Menor coste y menor tiempo de lanzamiento al mercado (entre versiones).
- Habilidades Analíticas: la generación de código requiere un análisis más profundo del dominio antes de implementar la solución a través del generador.
- Habilidades de Diseño: requiere un buen arquitecto, con una visión más amplia.
- Crecimiento Sano: previene la degradación de la arquitectura.
- Integración de Nuevos Miembros: la cultura o las normas de desarrollo son menores cuando se trabaja con generación de código.
- Nivel de abstracción: la programación a un nivel más abstracto, además de fácil de entender (es más intencional), abre la puerta a nuevas posibilidades, tales como: generación de pruebas unitarias, auto-documentación, carga automática de datos, semántica, racionamiento automático, etc.
La generación de código no es fácil, la implementación de un generador requiere de tiempo y esfuerzo, y más aún si se trata de un Language Workbench, pero, sin duda, los beneficios son enormes.
Ver todos los posts Teórico.
Buenas Prácticas en la Generación de Código
El error más común cuando generamos código es verlo como una caja negra, pensando que lo importante es «lo que hace» y no «cómo lo hace». Esto es un error. Como siempre, la calidad importa.
Estas son algunas de las características que un buen código generado debería tener:
Estas son algunas de las características que un buen código generado debería tener:
- Independiente: el código manual y el generado deben estar en archivos diferentes, de lo contrario se corre el riesgo de perder el primero en el caso de que tengamos que volver a generar el código (y sucederá).
- Inmutable: no se debe cambiar, por dos razones: es peligroso, por ser desconocido, y por la misma razón que en el caso anterior.
- Legible: eso significa: nombres de variables y funciones significativos, comentarios, sangría, organizados en carpetas, archivos, etc. El código generado debe estar presentable para recibir la visita de los desarrolladores: para saber cómo funciona y ¿por qué no?, para aprender de él. Debemos generar un código del que sentirnos orgullosos.
- Extensible: por diferentes razones es posible que tenga que implementar manualmente algunas funcionalidades, por lo que el código generado debe dejar algunas puertas abiertas. La mejor manera es diseñar el código generado como un Framework, donde el código manual puede extender sólo algunas funcionalidades permitidas y en un entorno seguro.
- Estructurada: elevar el nivel de abstracción requiere un buen conocimiento del campo que se está tratando. Un código mal estructurado puede ser un síntoma de que ese campo no está completamente bajo control. Una buena generación de código requiere un buen arquitecto.
- Robusto: el código generado puede fallar, por supuesto. El control de errores, la gestión de excepciones, la validación de las entradas, validaciones internas, etc deben ir siempre incluidas en el código. Este tipo de políticas de seguridad se pueden implementar fácilmente en la generación de código y debe ser una de las razones de su calidad.
- Potente: una vez dicho lo anterior, deberíamos ver la generación de código como una forma de escribir un código más potente, eso significa pensar en estrategias, en el código generado, que nunca usaríamos si lo hiciéramos a mano (por lo general por razones de mantenimiento).
En resumen, las buenas prácticas en la generación de código son una mezcla de las buenas prácticas tradicionales y una forma más amplia de pensar.
Ver todos los posts Teórico.
Ver todos los posts Teórico.
¿Por qué generación de código?
La generación de código no es un nuevo estilo o técnica, es el camino seguido por los lenguajes de programación para hacer frente a la complejidad, desde la codificación en binario hasta la primera, segunda y demás generaciones de lenguajes. Es lo que los compiladores han estado haciendo desde el inicio.
El tema clave aquí es «hacer frente a la complejidad». Mientras más complejo sea el problema más abstracto tiene que ser la forma de pensar para resolverlo. En otras palabras, es necesario elevar el nivel de abstracción. Y esta regla se aplica igualmente a las herramientas que se utilizan para resolver el problema: los lenguajes de programación.
Por lo tanto, podemos afirmar que «elevar el nivel de abstracción es el objetivo perseguido en la evolución de los lenguajes de programación».
Los lenguajes comunes que se utilizan hoy en día para resolver los problemas (Java, C #, C + + , Delphi … ), se conocen como “lenguajes de propósito general” (GPL en inglés ), y aquí está el problema: «propósito general», que significa que pueden resolver «todos» los problemas, pero desde una perspectiva global. Pueden resolver desde un nivel de abstracción lo suficientemente amplio como para llegar a la solución, pero no tan alto como lo que necesitaríamos en cada problema particular. Existe una brecha entre el nivel de abstracción que utilizamos para lidiar con el problema y el nivel de abstracción que utilizamos para resolverlo a través de GPLs.
¿Cómo podemos cubrir esa brecha? Obviamente, con la generación de código.
Como conclusión, para abordar adecuadamente un problema tenemos que encontrar un lenguaje particular para definir la solución en el nivel de abstracción que cada problema requiere. Con el fin de hacer que la solución sea computable, tenemos que generar código, por lo general en el nivel inferior más cercano: el de GPL.
Esos lenguajes particulares se conocen como “lenguajes específicos de dominio” (DSL en inglés), pero este tema se abordará en otro post.
Como conclusión, decir que este enfoque no es solo aplicable a problemas de negocio sino también a la resolución de problemas técnicos. Por ejemplo, los nuevos retos que ofrece la programación de aplicativos web de escritorio requieren un enfoque más abstracto que integre todas las tecnologías: HTML, CSS, JavaScrpit, AJAX y otros.
Ver todos los posts Teórico.
El tema clave aquí es «hacer frente a la complejidad». Mientras más complejo sea el problema más abstracto tiene que ser la forma de pensar para resolverlo. En otras palabras, es necesario elevar el nivel de abstracción. Y esta regla se aplica igualmente a las herramientas que se utilizan para resolver el problema: los lenguajes de programación.
Por lo tanto, podemos afirmar que «elevar el nivel de abstracción es el objetivo perseguido en la evolución de los lenguajes de programación».
Los lenguajes comunes que se utilizan hoy en día para resolver los problemas (Java, C #, C + + , Delphi … ), se conocen como “lenguajes de propósito general” (GPL en inglés ), y aquí está el problema: «propósito general», que significa que pueden resolver «todos» los problemas, pero desde una perspectiva global. Pueden resolver desde un nivel de abstracción lo suficientemente amplio como para llegar a la solución, pero no tan alto como lo que necesitaríamos en cada problema particular. Existe una brecha entre el nivel de abstracción que utilizamos para lidiar con el problema y el nivel de abstracción que utilizamos para resolverlo a través de GPLs.
¿Cómo podemos cubrir esa brecha? Obviamente, con la generación de código.
Como conclusión, para abordar adecuadamente un problema tenemos que encontrar un lenguaje particular para definir la solución en el nivel de abstracción que cada problema requiere. Con el fin de hacer que la solución sea computable, tenemos que generar código, por lo general en el nivel inferior más cercano: el de GPL.
Esos lenguajes particulares se conocen como “lenguajes específicos de dominio” (DSL en inglés), pero este tema se abordará en otro post.
Como conclusión, decir que este enfoque no es solo aplicable a problemas de negocio sino también a la resolución de problemas técnicos. Por ejemplo, los nuevos retos que ofrece la programación de aplicativos web de escritorio requieren un enfoque más abstracto que integre todas las tecnologías: HTML, CSS, JavaScrpit, AJAX y otros.
Ver todos los posts Teórico.
Glosario
Comenzamos nuestros artículos de carácter académico con el glosario de términos de la metodología.
- AOP
- Aspect-oriented programming. La programación orientada a aspectos es un paradigma de programación que permite la separación de aspectos trasversales. Aspectos diferentes, tales como seguridad, log contable, avisos, etc. pueden ser definidos en áreas diferentes, obteniéndose el comportamiento final del sistema mediante a través de un proceso de tejido.
- Dominio
- Un dominio es un área, de negocio en nuestro caso, en el cual reside un conocimiento particular y una terminología específica para definirlo.
- DSL
- Domain Specific Language. Un lenguaje específico de dominio es un lenguaje de programación diseñado para representar los conceptos de un dominio dado. Puede ser tanto gráfico como texto.
- FW
- Framework. Un framework es una plataforma software reutilizable para desarrollar aplicaciones. Se trata de una abstracción donde sus funcionalidades genéricas pueden ser extendidas de manera selectiva para conseguir un aplicación software específica.
- FM
- Feature Model. Modelo para representar las partes comunes y opcionales que puede haber en una línea de producción. Es utilizado en PLE.
- LW
- Language Workbench. Herramienta que permite la definición y uso de lenguajes formales: sintaxis abstracta y concreta y semántica estática y dinámica. Se podría considerar como una herramienta para definir el lenguaje, el compilador y el IDE de un determinado dominio.
- MDA
- Model Driven Architecture. Estándar OMG para el desarrollo de software basado en modelos. Se puede considerar como un caso particular de MDSD.
- MDSD
- Model-driven Software Development. Se trata de un paaradigma de programación que basa el desarrollo de software a nivel de modelos.
- Meta-modelo
- Reglas, construcciones, relaciones, etc. que definen los modelos que pueden ser construidos en un dominio determinado.
- PLE
- Product Line Engineering. Disciplina para la creación de software a través de líneas de producción de software (SPL).
- SPL
- Software Product Lines. Metodología de desarrollo enfocada en la producción de software tal y como se hace en la producción de otros bienes: compartiendo los procesos comunes y aislando los particulares.
Ver todos los posts Teórico.
Automatización de software. Introducción
La automatización del desarrollo de software, como todo proceso de automatización, consiste en delegar a la máquina algunas de las tareas que implica este proceso productivo. El objetivo es conseguir una metodología de desarrollo más rápida, y por tanto con menos costes, así como una mayor calidad en el producto final.
La automatización en el SW ha sido una meta perseguida con anterioridad aunque no con mucho éxito. Estándares de diseño tipo UML o herramientas de tipo CASE (Computer Aided Software Engineering) no han conseguido los frutos esperados debido a que intentan dar una solución genérica (de “propósito general”) al conjunto de problemas a los que el SW intenta dar respuesta.
Por el contrario, los nuevos métodos de automatización ofrecen la posibilidad de diseñar, de forma simple y rápida, lenguajes que se adapten y puedan describir cada problema particular. Es este enfoque específico, y no de propósito general, el que permite lograr casos de éxito en la automatización del desarrollo de sw.
La automatización se asocia principalmente a la generación de código porque al fin y al cabo, el código fuente, es el resultado del proceso productivo, pero no conviene olvidar que una vez que se utilizan estas técnicas, la programación pasa de ser una mera declaración funcional a una verdadera representación del conocimiento, a partir de lo cual se pueden aplicar diversas disciplinas como la semántica o el razonamiento automatizado.
Podemos concluir esta introducción diciendo que a lo largo de la historia el sw a optimizado muchos procesos productivos, es el momento de que optimice el suyo propio.
Con este artículo iniciamos una serie en la que iremos describiendo en profundidad esta disciplina así como su implementación en Bheudek.
Ver todos los posts Teórico.
La automatización en el SW ha sido una meta perseguida con anterioridad aunque no con mucho éxito. Estándares de diseño tipo UML o herramientas de tipo CASE (Computer Aided Software Engineering) no han conseguido los frutos esperados debido a que intentan dar una solución genérica (de “propósito general”) al conjunto de problemas a los que el SW intenta dar respuesta.
Por el contrario, los nuevos métodos de automatización ofrecen la posibilidad de diseñar, de forma simple y rápida, lenguajes que se adapten y puedan describir cada problema particular. Es este enfoque específico, y no de propósito general, el que permite lograr casos de éxito en la automatización del desarrollo de sw.
La automatización se asocia principalmente a la generación de código porque al fin y al cabo, el código fuente, es el resultado del proceso productivo, pero no conviene olvidar que una vez que se utilizan estas técnicas, la programación pasa de ser una mera declaración funcional a una verdadera representación del conocimiento, a partir de lo cual se pueden aplicar diversas disciplinas como la semántica o el razonamiento automatizado.
Podemos concluir esta introducción diciendo que a lo largo de la historia el sw a optimizado muchos procesos productivos, es el momento de que optimice el suyo propio.
Con este artículo iniciamos una serie en la que iremos describiendo en profundidad esta disciplina así como su implementación en Bheudek.
Ver todos los posts Teórico.
Bheudek 