nicosommi

software engineer

posts

slides

about

Generation Driven Development – Introducción a la idea y a gddify

May 26, 2016
6 min read

gddify en github

read this article in english

Mantenga los bloques de codigo en sus componentes de software actualizados. Incluso perteneciendo al mismo archivo.

Mantenga los bloques de código en sus componentes de software actualizados. Incluso perteneciendo al mismo archivo.

Nota: GDD y gddify son un trabajo en curso.

Las aplicaciones, son ni mas ni menos que materializaciones de un punto de vista. Un punto de vista que esta compuesto por los puntos de vista de los participantes del desarrollo de la misma. Sobre todo de los programadores que son quienes crean entidades que abstraen el comportamiento real del flujo de la información a lenguajes de programación.

Los puntos de vista, o modelos, se podría decir que son lo observado, mas una carga subjetiva del observador, una meta información. Para los mas técnicos: payload y meta.

Durante los últimos años me vi muchas veces desarrollando generadores de código. Ya sea utilizando templates (de los miles que hay), o con yeoman (que esta de moda y utiliza templates), o con algún script personalizado.

También, durante los últimos años, he visto el avance de las Promesas. Estos objetos de javascript que nos prometen la entrega de algo a futuro. Este concepto me pareció siempre muy interesante, y acertado a la vez. Es que no sólo simplifica el modo de escribir funciones, también elimina ambigüedades. Pero por sobre todo, representa mejor la realidad. Y esto es lo que me quiero llevar para explicar GDD (Generation Driven Development).

A la hora de generar codigo, los programadores estamos acostumbrados ya a usar templates, a utilizar yeoman, o a hacer cosas raras. Sin embargo, si observamos la realidad, un template (benditos templates no me animaría a criticarlos… despues de tantas veces que me han salvado!) es mas bien algo totalmente imposible en el mundo físico, sencillamente no tiene sentido poner dos cosas en el mismo lugar de manera literal. La “mezcla”, en la realidad se produce por ejemplo, por reproducción a nivel celular que luego, crece.

Ahora bien, alguien podria decir que si bien no sea una fiel representacion de la realidad, los templates han servido a numerosos objetivos y aun lo hacen. Es totalmente cierto. Pero creo que una representación de la realidad mas atinada, como lo hicieron las promesas, tambien simplificara el proceso de desarrollo.

Toda esta introducción, sumada a necesidades actuales como los microservicios que tiene una carga de mantenimiento de muchos proyectos muy grande (de hecho sigue el single responsibility pattern o patrón de responsabilidad simple), las constantes actualizaciones de librerías, las librerías abandonadas, las compatibilidades que se rompen, la lisa y llana repetición de patrones de operaciones, etc, etc. y ademas sumado a la carga que lleva hoy en dia el desarrollo de generadores, el bajo nivel de test (o de alto esfuerzo en su realizacion) que se puede efectuar sobre los templates y su bajo soporte por los IDE… todo esto como decia, me ha llevado a pensar en que allí había algo por mejorar.

Volviendo a lo de los puntos de vista. Las aplicaciones son puntos de vista concretos. Ahora bien, si pensamos en generar como siendo esto generar mas puntos de vista, debemos prestar especial atención a la meta información de dichos puntos de vista, que son la percepción de la realidad, para crear y mantener otras percepciones similares. Debemos observar al observador para recrearlo.

De este concepto, he creado esta practica de desarrollo que llame GDD, que no es ni mas ni menos que añadir en el código fuente, información necesaria para poder generarlo, utilizando como principal herramienta el principal elemento para la meta información del código fuente: los comentarios.

Cual es la informacion necesaria?

Eso puede ser una larga discusion y seguramente con el paso del tiempo y quizas con la colaboracion de la comunidad podre encontrar cosas que aun no he detectado. Actualmente, en la herramienta para implementar GDD que he desarrollado, gddify, he agregado soporte para lo que mi experiencia me ha marcado (mi punto de vista actual para generar puntos de vista), veamos estos elementos uno a uno:

  • componente sw (swComponent): es un componente software, que consta de bloques sw. Un proyecto. Por ejemplo, una aplicacion web, un api, un microservicio, o cualquier proyecto.
  • bloques sw (swBlock): es un bloque de software, un conjunto de archivos dentro de un componente, con una funcion particular. Por ejemplo, los archivos de codigo que ejecutan el build, los archivos de un CRUD (o SCUDL), o cualquier otra agrupacion que tenga un significado logico o practico para nuestra arquitectura.
  • archivo de codigo fuente (source code files): este es la unidad base de sincronizacion/generacion. Es un archivo.
place holders
Dentro de los place holders, se mandentra el codigo del archivo actual a pesar de las actualizaciones
  • contenedores (place holders): estos son bloques de codigo que mantienen su contenido siempre para el archivo actual, mas alla de las sincronizaciones que pudiesen ocurrir con otros archivos. Se delimita con meta informacion.

Ejemplo de implementacion en gddify (js)

/* ph constructor */
constructor () {
  this.name = 'nico'
}
/* endph */
  • reemplazos (replacements): objetos de informacion para reemplazos, que seran utilizados en la sincronizacion. Sus atributos actuales en gddify son name (nombre, que se utilizara para encontrar correspondencias entre archivos), regex (expresion regular de javascript que utilizaran otros archivos para sincronizarse con este), y value (valor que este archivo tendra en esos reemplazos).

    Ejemplo de implementacion en gddify (js), notar que es esta contenido dentro de un placeholder especial denominado replacements, y que sus atributos estan separados por comas. Habra una linea para cada atributo.

/* ph replacements */
/* name, /myClass/g, myClass */
/* endph */

replacements

un ejemplo complejo de reemplazos

  • estampas (stamps): bloques de codigo que no cambiaran para ninguno de los archivos sincronizados, pero que pueden ser omitidos con otro objeto denominado ignoringStamps (siguiente)

    Ejemplo en gddify (js)

/* stamp toJson */
toJSON () {
  return { name: this.name }
}
/* endstamp */

stamps

Los stamps son bloques de codigo compartidos e inmutables entre componentes (pero que se pueden ignorar)

  • estampas ignoradas (ignoringStamps): array de nombres de estampas cuyo contenido este archivo no incluira si apareciesen en una sincronizacion con otro archivo.

    Ejemplo en gddify (js). Notar que al igual que los reemplazos, se encuentra dentro de un place holder especial, en este caso denominado ignoringStamps

/* ph ignoringStamps */
/* toJson, parse */
/* endstamp */

Ignoring stamps

Ignoring stamps son aquellos bloques inmutables que no queremos mostrar en este archivo en particular

La descripción de estos componentes de software de manera correcta, nos permitirá no solo generarlos en el futuro, sino generar particularmente bloques individuales pudiendo combinarlos, y ademas mantenerlos actualizados, sin esfuerzo adicional en la construcción de generadores, y en un solo lenguaje sin templates. He allí el valor que creo que este modo de desarrollar tiene gracias al cambio de modelo con el que ataca el problema que considero es mas cercano a al sentido común.

Actualmente una arquitectura de microservicios tiene una desventaja muy importante que es la dificultad de mantenimiento. Esto ocurre mas alla del delivery continuo, de la integración continua, etc. Esto es debido a lo costoso de mantener muchos proyectos.

Por otro lado, este trabajo genera des-sincronizacion por falta del adecuado mantenimiento, impactando en la calidad de los componentes producidos.

Considero que GDD tiene el potencial de disminuir ese costo considerablemente ya que permite compartir bloques de código y archivos entre proyectos, manteniendolos actualizados de manera sencilla, y asi acercar los microservicios y otras arquitecturas complejas que requieren modularización a todo el mundo y no solo a quienes puedan afrontar altos gastos en el departamento de sistemas. Mejorar el mundo de las aplicaciones en calidad y precio. Ese es mi objetivo personal y el compromiso y la visión de Integraciones Agiles.

Conclusión

Esto es una simple introducción al modelo de visualizar el problema, pronto publicare mas detalles de la usabilidad del mismo, de como acostumbrarse, problemas frecuentes, ejemplos de aplicación, códigos de ejemplo, y mucho mas.

Colaboración

Me encuentro desarrollando esto de manera open source y sin ganar dinero a cambio, y para poder continuar dedicando tiempo a estos proyectos, necesito el aporte de la comunidad. Por favor no dude en contactarme si esta interesado en temas de donaciones, servicios, consultoria, negocios, etc.

http://integracionesagiles.com

gddify en github

nico
Copyright by nicosommi 🐱