Seguí jugando con el plugin City Model para Sonar de eXcentia.

Para quienes se perdieron los anteriores episodios, los puedes encontrar aquí: City Model, City Model – Nueva versión, La métrica ABC.

Este plugin es muy divertido. Y todo el mundo me dice que es fantástica la representación visual del código en forma de una ciudad. Ir rápidamente a lo más importante es precioso cuando se debe evaluar periódicamente la calidad de una aplicación.

Así que pensé a unos casos sencillos pero bastante usuales donde su uso será de gran valor. Esto también me dará la oportunidad de demostrar lo fácil que es de configurar con diferentes métricas o formulas.

Ciudad crítica

Un cliente me pide una auditoría de dos de sus aplicaciones. Le hago diferentes preguntas para conocer el “por qué” de esta auditoría. Puede haber varias razones, y necesito saber un poco más con el fin de responder con precisión a su petición.

Por ejemplo: el quiere externalizar esas dos aplicaciones bastante viejas, y antes de realizar un RFP, le gustaría saber cuál es el nivel de calidad. De hecho, es una buena idea, que le permitirá apreciar mejor las ofertas que se presenten y precisar los costes de mantenimiento. En la actualidad, muchos proveedores están dispuestos a hacer cualquier cosa para conseguir un contrato. Una estimación de la deuda técnica de estas aplicaciones le permitirá rechazar las ofertas ‘low cost’, poco realistas.

Otro caso: se le pide a un jefe de un centro de desarrollo que se encarga de una aplicación. Bastante complicada a primera vista: cientos de miles de líneas de código .NET, frameworks propietários, sin documentación, etc.. Hay de que ser un poco sospechoso. Le gustaría tener un poco de visibilidad respecto a la calidad de esta aplicación y el esfuerzo para recuperar este código, antes de aceptarla. O conseguir alguna información que le permite rechazarla.

De hecho, este cliente utiliza una de esos proveedores ‘low cost’ y resulta un poco fastidioso: retrasos en planificación, presupuestos en aumento con discusiones difíciles, muchos errores y los usuarios descontentos, algunas situaciones de crisis, degradación de la imagen de TI, etc. Bueno, el está buscando algunos motivos para poder explicar a su proveedor de que ya, basta.

Pues ahora, sé cómo ir a lo más importante. Violaciones críticas. Muéstrele algunos buenos defectos bien horrorosos.

Puse en marcha un análisis de código con Sonar desde Jenkins. Muy sencillo: Sonar – Jenkins plugin. Y muy rapido.

Luego me conecté como Admin en mi dashboard Sonar preferido:

Entré en la configuración de los widgets para añadir un widget City Model Top de eXcentia.

Con los siguientes parámetros:

• title: Blocker
• topListLength: 5. Quiero ver únicamente las 5 primeras violaciones de tipo ‘bloqueantes’.
• formula: {blocker_violations}.

La fórmula corresponde al top 5 de los componentes con más violaciones de tipo ‘Blocker’. Las que no se quiere ver en ninguna aplicación. Las que presentan más riesgos para los usuarios. Las que demuestran que el outsourcer produce un código de la peor calidad que sea.

Luego voy a añadir el widget City Model y a modificar sus parámetros. El primer campo ‘heightExp’ contiene una fórmula para definir la altura de cada edificio según la talla de cada clase en número de líneas de código (Lines Of Code o LOC).

Esta medida utiliza una función logarítmica con el fin de evitar un crecimiento demasiado rápido y pues una diferencia de talla que haría que ciertos ‘rascacielos’ salían del campo visual y que otros edificios parecen minúsculos. Voy a modificarla con una otra métrica: el número de ‘violaciones’ de buenas prácticas, es decir el número de defectos encontrados en el código:

Math.pow(Math.E – 0.25, Math.log({violations}))

Los otros parámetros son los siguientes:

• title: Blocker.
• colorExp: num2col({blocker_violations}, 0, 1).
• widthExp: {functions}.

Quiero que los edificios aparezcan en rojo cuando existe por lo menos una violación crítica, de tipo ‘Blocker’. Pues la fórmula ‘colorExp’ admite sólo un intervalo muy estrecho de valores: verde para 0 ‘blocker’ y rojo desde que existe por lo menos un defecto bloqueante, medido por la métrica {blocker_violations}.

Una vez guardados estos valores, he aquí lo que se parece a mi ‘Ciudad crítica’:

No olivdes que puedes hacer zoom en esta representación o girar horizontalmente o verticalmente, lo cual nos permitirá identificar los ‘Blockers’ de una o más clases.

Esta gran torre verde a la derecha tiene muchos defectos, pero nada crítico. Otras clases, incluso con un mayor número de métodos, tienen al menos una violación bloqueante.

Estos defectos deben ser corregidos obligatoriamente antes de que la aplicación sea sometida a pruebas o instalada en el entorno de producción.

Navegando en esta representación 3D, podemos encontrar clases que de otro modo serían indetectables de por sus pequeñas dimensiones, en número de líneas de código o de métodos o de complejidad, pero que cuentan sin embargo un bug de tipo ‘Blocker’.

Podemos ver en la parte inferior izquierda tres clases pequeñas, con sólo dos métodos y por lo menos un fallo bloqueante.

Ahora también queremos identificar las clases con un alto número de defectos críticos o mayores. Estas son las reglas elegidas con el cliente:

1. Una clase es de color rojo si tiene al menos una violación ‘Blocker’.
2. Una clase es de color rojo si tiene al menos cuatro violaciones ‘Critical’. De lo contrario, el color va de verde a rojo en función de una escala de 1 a 4 de estas violaciones.
3. Si la clase no tiene ni defecto bloqueante ni crítico, su color se define de acuerdo con el número de defectos ‘Major’ en una escala de 1 a 100.

Entonces, en una escala de 1 a 100:

• Una violación bloqueante = 100.
• 4 defectos críticos = 100, 3 defectos críticos = 75, 2 defectos críticos y 1 defecto crítico = 25.
• Los defectos ‘Major’ se miden sin factor multiplicativo.

Y última regla, el color del edificio se define de acuerdo con el más alto de estos valores. Por ejemplo:

• Una clase con 30 violaciones ‘Major’ sin bloqueante o crítica tendrá un color (de verde a rojo) igual a 30 en una escala de 1 a 100.
• Una clase con 2 defectos críticos sin ‘Blocker’ o ‘Major’ tendrá un color igual a 50 o 2 violaciones ‘Critical’ x 25.
• Una clase con 2 defectos críticos y 30 violaciones mayores tendrá un valor de 50 (el más alto de los dos valores).
• Una clase con 2 defectos críticos y 60 violaciones mayores tendrá un valor de 60.

Y aquí está la fórmula correspondiente a estas reglas:

num2col(Math.max(({blocker_violations}*100), ({critical_violations}*25), {major_violations}), 0, 100)

El resultado:

He personalizado mi dashboard con 3 listas City Model Top que corresponden a estos tres tipos de defecto:

Algunas clases con ‘Blockers’ tienen también un alto número de defectos ‘Major’.

Conclusión

El cliente será sin duda satisfecho. Por otra parte, los datos conseguidos son una base de información objetiva que permiten evitar la típica confrontación «cliente-proveedor» en favor de un diálogo más constructivo y realista. El cliente se acordará de esto a la hora de elegir el proveedor a quien confiará sus aplicaciones.

Otro ejemplo, puede usar estos plugins como Quality Gate:

• Análizar periódicamente el código con estos plugins.
• Corregir inmediatamente cualquier clase en rojo.
• Realizar un análisis final antes de entregar una nueva versión de la aplicación o de sus módulos y enseñar al cliente el dashboard Sonar con la ciudad correspondiente.
• Puede permitirse algunos defectos, en caso de emergencia, pero planificando corregirlos más tarde.

En cualquier caso, te recomiendo utilizar estos plugins Sonar antes de que tu cliente les descubre. O que se los presente.