Reutilización: más allá del catálogo de componentes

08 Feb 2022

Fruto del reconocimiento con el que cuentan los marcos de trabajo de DevOps, es bastante común que aquellas compañías orientadas al desarrollo de software que cuenten con un grado de madurez medio o alto, dispongan de pipelines específicos para agilizar el desarrollo y despliegue continuo de sus aplicativos: procesos de calidad integrados, testing,  quality gates, reporting, securización, publicación en distintos entornos, etc. No cabe la menor duda de que éste conforma un enorme paso en cuanto a agilidad y estandarización de los procesos, pero debemos de dar un paso atrás para empezar a optimizar desde el principio.

¿Qué optimizaciones podríamos llevar a cabo en tiempo de desarrollo?

¿Podríamos acelerar el modo en el que construimos el software suplementando las mismas herramientas y SDKs de desarrollo? Esta es precisamente una iniciativa en la que desde VASS llevamos trabajando durante años. Por un lado, de manera in-house, con la construcción de nuestro propio framework funcionalmente agnóstico. Y, por otro, a través de la colaboración con clientes y terceros con los que trabajamos en la definición de los procesos colaborativos y la prescripción de las buenas prácticas tecnológicas y organizativas. Pero hagamos una puntualización a esto: construir un framework de desarrollo acelerado ya no es en sí mismo innovación” (es una práctica bastante extendida). Lo que sí lo es, es hacerlo funcionar bien, respondiendo a las necesidades de una organización. Y esto no es trivial, porque es necesario contar con profesionales con la capacidad de conectar dos mundos de naturaleza inconexa: tecnología y negocio. Ese es el verdadero reto al que nos enfrentamos.

La creación de un framework acelerador debe de contar con el soporte de la Dirección

En la actualidad, multitud de compañías están realizando importantes inversiones en la construcción de piezas de software reutilizables (catálogos, plantillas, librerías…) que permiten acelerar sus tiempos de desarrollo y minimizar sus esfuerzos en la construcción y mantenimiento de nuevas aplicaciones. Pero de manera empírica, comprobamos reiteradamente cómo equipos formados por los mejores técnicos y responsables de los departamentos de Arquitectura IT fracasan constantemente en su iniciativa de construir dichos aceleradores. Lo que sucede, en la mayoría de los casos, por la falta de soporte o aprobación de otras áreas clave de la compañía o por resolver problemas de nicho que no atienden a una necesidad global de la corporación.

Diferentes iniciativas de arquitectura con un objetivo único

Dichas iniciativas se componen de líneas de trabajo independientes que focalizan los esfuerzos principalmente en las capas de presentación, dominio y aprovisionamiento de información, así como en la estandarización de las interfaces que conectan dichas capas. De este modo, las piezas de software se coordinan en un producto único que canaliza los procesos funcionales diseñados desde los equipos de negocio de toda la compañía, hasta la representación visual que los define, aplicando la imagen de marca o branding. Sin embargo, las malas praxis aplicadas fruto de una evolución no controlada o incorrectamente dirigida de estos aceleradores, convierte estos activos en soluciones degradadas que lastran la eficiencia de los equipos de desarrollo y se alejan progresivamente de los objetivos para los que fueron creados.

El catálogo de componentes UI como punta de lanza de la reutilización

El presente post pretende ser el origen de una serie de artículos donde descubriremos algunas de nuestras mejores prácticas y, por qué no, también algunos de los pain points más recurrentes extraídos directamente de la realidad de los entornos en los que hemos trabajado. En los sucesivos artículos vamos a empezar hablando de los conceptos básicos asociados a las iniciativas de capa de presentación, y principalmente a los Catálogos de Componentes de Interfaz (en adelante, Catálogos de Componentes). Su objetivo será el de suplementar las capacidades de distintos Frameworks base (por ejemplo, para la aplicación una guía de estilos común, a través de la sobrecarga de métodos, del control de los orígenes de poblado de vistas, la aplicación de lógicas de renderización, comportamiento, etc.) proporcionando así la construcción acelerada de interfaces visuales.

Las conclusiones que expondremos en los posteriores artículos son las lecciones aprendidas de las experiencias de colaboración continuada y el conocimiento generado a lo largo del tiempo por el Área de Movilidad de VASS. De este modo, hemos operado tanto con el rol de prescriptor como con el de consumidor de Catálogos de Componentes, con diferentes grados madurez, alcances locales o globales, Frameworks de desarrollo, etc.

Debido al fuerte acoplamiento tecnológico al que se suscriben estas iniciativas, los sucesivos artículos perseguirán mantener el mayor nivel de abstracción tecnológica con el objetivo proporcionar directrices igualmente válidas y aplicables al mayor número de compañías sin importar el framework sobre el que estas desarrollen sus aplicativos. En cualquier caso, estas iniciativas deberán de ser revisadas y adaptadas para cada caso particular.