El desarrollo de una aplicación es un trabajo en equipo. Requiere habilidades complementarias para que funcione sin problemas. Sin embargo, los errores se producen con frecuencia y no es fácil leer el código y todas sus interdependencias. Así que lo más fácil sería llamar a tu colega que ha trabajado en ella, pero tiene una gripe y no puede responderte. Para evitar este tipo de situaciones, utilizamos herramientas que nos ayudan a visualizar el código base de la aplicación. En este artículo, te presentaremos una de ellas que utilizamos con frecuencia: Moose.
Desarrollar aplicaciones es una tarea tediosa. No es como editar un documento de Word. El código no es lineal. De hecho, el código puede verse como un gráfico. Las clases, los métodos y los atributos son nodos conectados a otros. Al realizar un algoritmo, hay que seguir las relaciones entre todos esos nodos para entender el programa.
La mayoría de los desarrolladores están acostumbrados a la visualización UML (Unified Modeling Language) o a alguna representación arquitectónica de su código. Ese tipo de representaciones son estupendas porque son comprensibles para cualquiera, pero no representan necesariamente nuestro problema. Además, a menudo están desfasadas, o son demasiado grandes (en el caso de aplicaciones enormes) para ser comprensibles.
Para mejorar la comprensión de nuestros sistemas, se han desarrollado herramientas automáticas que analizan nuestro código base y nos ofrecen una visualización previa a la construcción, así como herramientas para crear la nuestra. Uno de los principales actores para analizar los sistemas de software es Moose.
¿Por qué visualizamos el código en Berger-Levrault?
Cuando desarrollan aplicaciones, nuestros equipos utilizan varias herramientas para ayudarles: Entornos de desarrollo integrados (IDE) como Eclipse, VSCode o Intellij Idea, herramientas para probar automáticamente su código como GitLab CI, herramientas para evaluar la calidad de su código como SonarQube y herramientas para evaluar la cobertura del código (SonarQube, de nuevo). También utilizamos herramientas para gestionar la modificación que tenemos que realizar en un sistema de software como Jira o GitLab.
Todas estas herramientas evalúan la calidad del proyecto o ayudan a gestionar la modificación. Pero no ayudan en comprensión de los sistemas de software. Sin embargo, la comprensión de un sistema de software es esencial para el mantenimiento de grandes aplicaciones. ¿Cuál es la parte de mi sistema que más tengo que modificar? ¿Dónde se implementan los códigos de negocio, vinculados a qué tickets de Jira? ¿Cuáles son las dependencias de código y cómo matar algunas para independizar las características de las otras? Para solucionar este problema, tengo que modificar esta clase, y cuáles otras? ¿Pueden los desarrolladores recién llegados trabajar en la aplicación y mantenerla correctamente de forma rápida? Todas estas cuestiones son cruciales para mantener las grandes aplicaciones a lo largo de los años. Sin embargo, a menudo, la gente piense en tienen un buen conocimiento del sistema de software porque acaban de desarrollarlo.
Todas estas preguntas pueden responderse mediante la visualización. Es más, la visualización, basada en métricas, señalará el problema y así ayudará a mejorar el sistema de software y a reducir la deuda técnica. Y recuerde, no es porque alguien haya desarrollado una aplicación que la persona tenga un buen conocimiento del sistema de software.
Plataforma Moose
Moose es una plataforma de código abierto para el análisis de software basada en Pharo. Nos permite representar sistemas de software en modelos, y consultar, manipular, transformar y visualizar estos modelos. Utilizando Moose, el proceso para analizar un nuevo proyecto es más que sencillo:
- Dale a Moose tu código base
- Moose lo importa en un modelo
- Moose genera informes y visualizaciones de su código
- Manipular la información de Moose
Algunos ejemplos
El equipo de DRIT utiliza Moose para comprender mejor el código de nuestra aplicación. Dado que no somos expertos en actividades, Moose nos resulta útil para entender la arquitectura de la aplicación que está influenciada por el campo de la actividad. Por ejemplo, podemos utilizarlo para recuperar la arquitectura de la aplicación.
Arquitectura de servicios
Por ejemplo, una de nuestras preocupaciones es extraer la arquitectura de los servicios. Los servicios de la aplicación están bien separados, o existe alguna dependencia cruzada que pueda crear errores al transformar una aplicación monolítica en una de microservicios?
Mantener el código base
¿Qué parte de su base de código tiene más errores? ¿Necesita más mantenimiento? ¿Y todos los desarrolladores mantienen todas las partes del código? ¿O un solo desarrollador mantiene una parte crítica del código base?
La figura anterior presenta las clases de un proyecto BL. Cada cuadrado corresponde a una clase y cada color es un desarrollador (o un grupo de desarrolladores para el cuadrado rojo). Utilizando esta visualización, es posible determinar que algunos paquetes sólo son mantenidos por un desarrollador. ¿Qué pasa si este desarrollador decide dejar la empresa? Ahora podemos pedir a otros desarrolladores que aprendan diferentes partes del sistema para ser más resistentes.
Otra visualización es el HeatMap. Permite encontrar rápidamente los archivos más modificados en los commits recientes, y el issue/ticket de Jira asociado a la modificación. Este tipo de representaciones son especialmente interesantes para detectar el código que está más sujeto a modificaciones y, por tanto, el código que debe ser más probado.
Visualización clásica
Por último, quien puede hacer más puede hacer menos.
Además del análisis específico, también es posible realizar más análisis del código. Por ejemplo: generar UML a partir de un conjunto de clases, encontrar dependencias mediante una representación DSM (o un gráfico), utilizar el mapa de distribución y la complejidad del sistema para descubrir malos olores y clases complejas, y acabar con la duplicación gracias a un algoritmo avanzado de búsqueda de duplicados.
Haz algo más que visualizar tu código
Visualizar tu código base es genial, pero puedes hacer más. Por ejemplo, Moose viene con herramientas para manipular modelos. Así, es posible realizar la refactorización utilizando toda la potencia de la herramienta. Un ejemplo conocido en Berger-Levrault es el Casino herramienta que realiza la migración de front-ends de aplicaciones a Angular. Esta herramienta está totalmente desarrollada utilizando la plataforma Moose.
Para terminar este post, os presento los fuegos artificiales: una visualización de la UI de una de las aplicaciones de BL.
