Hemos visto la semana pasada los diferentes niveles de madurez en la calidad del software y como la medición de la deuda técnica nos ayuda a progresar a través de estos diferentes niveles, para una gestión proactiva e optimizada de la calidad de las aplicaciones.

En esta ocasión, hablé de utilizar la deuda técnica en la presentación de un portafolio de aplicaciones. Entonces me pregunté como sería una representación 3D de una cartera de este tipo, con el plugin ‘3D City Model’ de eXcentia (1).

Ya lo he presentado en unos artículos anteriores: City Model, City Model – Nueva versión, Ciudad crítica, donde vimos cómo crear nuestras propias fórmulas para jugar con el modelo 3D, y finalmente La métrica ABC para investigar la métrica del mismo nombre.

Representación 3D de un portafolio

Tengo una instancia SonarQube con una cartera de varias aplicaciones, con 5,7 millones de líneas de código (MLOC) Cobol, 485.000 líneas de código (KLoc) ABAP (aplicaciones SAP) y 205 KLocs de J2EE. También, he creado cuatro portafolios ‘Cobol’, ‘J2EE’, ‘SAP’, ‘y un ‘Global’ que reúne a los tres anteriores, con la ayuda del  plugin ‘Views’ de SonarSource que puede agregar múltiples proyectos o análisis de código en una sola vista o ‘Views’ con el fin de consolidar diferentes métricas y mediciones en diferentes ejes: de negocios, tecnología, etc. Entonces, en diferentes portafolios.

Por desgracia, el plugin 3D City no funciona con ‘Views’, aunque eXcentia planea desarrollar esta funcionalidad en el futuro. Pero, afortunadamente, el plugin viene con un widget que me pareció bastante interesante para lo que yo quería hacer.

Pues empiezo una sesión como administrador para configurar los widgets de mi dashboard y a continuación, seleccionar el menú ‘3D Code Metrics’ para mostrar unicamente los widgets de este plugin, y seleccionar el widget ‘Filtered Megalopolis’:

Voy a configurarlo con un título para este gráfico, y en el combo-box ‘Project filter’, voy a elegir Projects’. Cualquier otro filtro basado en ‘Views’ no permite visualizar el modelo 3D, así que utilizo este widget para ver mi portafolio global, con todas sus aplicaciones.

Puedes utilizar diferentes filtros, lo que debería permitir agregar proyectos en diferentes ejes. Por ejemplo, puedo crear un filtro con todos los análisis cuyo nombre comienza con ‘Cobol’ y entonces agrupar todos los proyectos Cobol, al igual que una cartera específica para estas aplicaciones.

No insistiré más en la configuración del widget, os dejo descubrirlo (los articulos antes mencionados os ayudarán), así que voy a volver en el dashboard para trabajar con esta representación.

Puedes cliquear en el gráfico para mover tu ‘Ciudad’ en todas las direcciones, y también utilizar la rueda del ratón para cambiar su tamaño, es decir, su visión general. También puedes hacer clic en cualquier edificio para conseguir información sobre la aplicación que representa.

Aquí, podemos ver nuestra aplicación más importante, ‘Billing’ en Cobol, con 2,5 millones de lineas de código (MLoc) en 116 019 funciones (párrafos o secciones en Cobol, métodos Java, funciones para lenguajes L4G) y una Complejidad Ciclomática (CC ) de 434 218 puntos. Ah, eso es Cobol, muy grande eh? Aquí hay mucho trabajo.

Pero lo que sobre todo me llama la atención son las dos barras rojas al pie de esas gigantescas aplicaciones Cobol.

Tenemos dos aplicaciones Abap:

• CO_OT1 con casi 350 KLoc y más de 54 000 puntos de CC.
• CO_OT2 con menos de 100 KLoc y más de 14 000 puntos de CC.

Haciendo click en lo que parece un tubo de ensayo o un frasco en el menú del gráfico, puedo escoger diferentes valores para diferentes dimensiones de mi ciudad en 3D. Puedo ver que el color representa la complejidad por función, por lo que proporcionalmente, los objetos Abap de estas dos aplicaciones muy rojas son mucho más complejos que en otras aplicaciones.

Solamente con una primera observación de esta representación en 3D de la cartera global de aplicaciones, puedo identificar dos aplicaciones SAP con una mantenabilidad y una capacidad de pruebas (testabilidad) por debajo de las gigantescas aplicaciones Cobol!

Por cierto, el color es el criterio que vamos a utilizar lo más a menudo.

Por ejemplo, en el siguiente gráfico, he seleccionado la deuda técnica de ‘Blockers’, es decir, el coste de remediación de los defectos más problemáticos (violaciones de buenas prácticas de programación ‘bloqueantes’).

Vemos que la aplicación CO_OT2 es ahora verde, es decir sin ‘Issue’ de tipo ‘Blockers’, mientras que nuestra primera aplicación CO_OT1 tiene una  deuda técnica ‘bloqueante’ de 2 100 minutos (4 días y 3 horas).

¿Qué otra característica, posiblemente defectuosa, podemos identificar?

Aquí he puesto el porcentaje de lineas duplicadas, comúnmente llamado el código ‘Copiar/Pegar’. Cuanto más se duplican bloques de código, más difícil su mantenimiento porque tienes que reproducir cualquier cambio en cada bloque de código ‘Copiado/Pegado’, y el riesgo de error será alto si se olvida uno. En una aplicación tan difícil de testar, eso es jugar con el presupuesto de mantenimiento y la satisfacción – o insatisfacción – de los usuarios.

Este gráfico nos permite comprobar que el nivel de comentarios es correcto, lo que no es raro en las aplicaciones de tipo Legacy. El Cobol también es verde. A diferencia de los bloques rojos representando aplicaciones J2EE. Se ha puesto de moda no comentar más en Java.

Evaluación

Pues ahora yo sé que tengo dos aplicaciones SAP con una complejidad (por función) más elevada que en cualquier otra aplicación en el portafolio. Quién dice aplicación compleja dice aplicación difícil de probar. Con más de 50 000 puntos de CC, CO_OT1 requiere definir planes de pruebas con la mayor antelación posible en el proyecto (idealmente antes de la fase de desarrollo) y pruebas automatizadas con herramientas de testing, en particular para evitar regresiones, especialmente en un código con tantas duplicaciones. Además, un código complejo significa una mantenabilidad reducida, pues costes de evolución más importantes, y también un mayor riesgo de introducir defectos en el código durante estas evoluciones, y por lo tanto errores para el usuario final. Esto incrementa la necesidad de invertir en las pruebas.

Además, esta aplicación tiene una deuda técnica sobre los defectos de tipo ‘Blockers’, no muy importante, pero cuando voy a la pagina ‘Issue’ de esta aplicación, veo 40 violaciones en dos reglas ‘System C functions should not be used’ et ‘Internal source code processing statements should not be used’.

En ambos casos, son instrucciones reservadas por SAP, y pueden cambiar o desaparecer de una versión a otra. Esto es también uno de los principales problemas de un upgrade de versión SAP, de la más costoso que existen.

De hecho, encontrar estos 40 defectos ‘bloqueadores’ en esta aplicación CO_OT1 unicamente y no en las otras aplicaciones Abap me lleva a creer que este equipo de proyecto – o este outsourcer – no conoce esta regla fundamental. Un punto que comprobar, y tal vez pensar en un training.

Por último, la alta tasa de código duplicado compromete la mantenibilidad y la fiabilidad de la aplicación. Un motivo más para considerar una refactorización, con el objetivo de acercar la deuda técnica a un nivel aceptable. Dicho esto, la documentación de código – el nivel de comentarios – es decente y debería facilitar (relativamente) esta operación.

Conclusión

Obviamente, yo podría proceder a la evaluación de mi portafolio y obtener la misma información de otra manera, por ejemplo con el uso de esta página ‘Compare’ en SonarQube.

Probablemente la utilizaré para reunir en una misma tabla métricas y medidas que he identificado previamente con el plugin ‘3D City’. Sin embargo, eso necesitaría configurar esta página con todos los proyectos y con un número mucho mayor de métricas para identificar problemas potenciales en las diversas áreas de mis aplicaciones. La ventaja del modelo de ‘Ciudad 3D’ es:

• Identificación inmediata de las aplicaciones problemáticas.
• Una visualización más eficaz que una navegación en largas tablas con muchos mas números.
• La elección de las métricas más útiles en una auditoría de portafolio.
• Entonces, un diagnóstico más rápido y fácil.

Luego, puedo hacer un ‘zoom’ en las aplicaciones que he identificado y trabajar planes de acción que me permitan hacer frente a estos problemas, y cuantificar con mayor precisión los costes de remediación asociados con la deuda técnica.

Simple, eficaz y también divertido, este plugin ‘3D City’ es imprescindible. Sencillamente, a los clientes les encanta.

 

(1) Si quieres hacer lo mismo, puedes descargar una versión de prueba del plugin (dos semanas) aquí: http://www.excentia.es/es/plugins/city-model/descargar, o para versiones anteriores de SonarQube: http://www.excentia.es/es/plugins/city-model/versiones.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.