Tuve un buen regalo de Navidad.

Un plugin Sonar, desarrollado por eXcentia, una empresa de la hermosa ciudad de Valencia, que conoces si te interesan los eventos deportivos como la Copa América, Fórmula 1 y Moto GP, pero también conocida por su especialidad gastronómica: la paella.

Este add-on para Sonar utiliza la libreria WebGL y es una del framework QAlitaX de eXcentia. Proporciona una representación 3D de una aplicación en forma de una ciudad modelada a partir de las métricas Sonar. Encontrarás este plugin aquì en el sitio de eXcentia, disponible para Java.

Tenemos aquí un ejemplo que describe a la perfección cómo funciona:

• Los paquetes Java se representan como barrios.
• Las clases se representan como edificios.

Para cada clase:

• La altura del edificio representa el número de líneas de código.
• La anchura del edificio representa el número de métodos de clase.
• El color representa la complejidad, de muy poco verde hasta muy rojo.

Bueno. ¿Divertido no? No sólo es lo bastante entretenido, pero es especialmente útil.

Por lo general, cuando se hace una auditoría de calidad de una aplicación, no tiene mucha información. No es que no quieren darnos información, sino simplemente porque es rara o inexistente. ¿Por qué crees que se pide una evaluación?

Cuando tengo que hacer una auditoria de una aplicación, la primera cosa que quiero saber es: ¿qué tipo de software es? Antes de empezar, quiero calificar si se trata de un monstruo enorme que necesitará varias horas de análisis, o una lata de gusanos, con un montón de trozos de código muy complicado y con llamadas dinámicas.

Anteriormente, yo tomaba un poco de tiempo para revisar el código y tomando notas:

• ¿Cuántos directorios, para tener una idea de cuántos paquetes y su organización?
• ¿Cuántos archivos y cuales directorios con muchos archivos, para identificar los paquetes con más clases y entonces más funcionalidades.

Ahora, gracias a este plugin Sonar, puedo conseguir esta información sin esta fase previa a la investigación.

Si consideramos una aplicación con tres directorios principales: common, cliente y server. Puedo analizar solamente la primera carpeta y, en lugar de navegar en diferentes directorios, apuntar a cada área con el fin de tener una idea de la cantidad de paquetes y clases en cada paquete. En el siguiente ejemplo, podemos ver un paquete con una sola clase, de pequeño tamaño y baja complejidad. Nos lo confirma Sonar: sólo 5 métodos en unas pocas líneas de código y complejidad casi cero.También puedo identificar un componente inusual como este, con un gran número de getters y setters que representan a varios cientos de líneas de código, pero sin complejidad. Por lo tanto un componente que constituye una estructura de datos importante, pero sin ningún tratamiento especial, fácil de comprender y evolucionar. Nota para el equipo de control de calidad: pruebas sólo en los valores.La torre grande atrás: número de líneas de código alto, otra estructura de datos importante con un gran número de descriptores de acceso, pero también compleja y … algunos defectos importantes o críticos. Esta clase se va directamente al plan de remediación: dos fallos críticos que podrían afectar la seguridad de la aplicación, un gran número de atributos ‘private’ a cambiar por constantes y varios métodos a refundir para disminuir la complejidad y por lo tanto mejorar la legibilidad del código y la capacidad de evolución.

 

Pensabas que esta clase era enorme? Echa un vistazo a esto. He añadido la carpeta»cliente» a mi análisis Sonar (de hecho, Jenkins, ver nuestro post anterior) y no es un pequeño distrito.

Mira el ‘barrio’ a la izquierda, el paquete ‘common’, cómo se ve ahora muy pequeño.

 

 

Una vista por arriba me permite visualizar la estructura interna del paquete ‘cliente’, el número y tamaño de sus clases, y identificar algunos de los componentes que investigar más tarde.

¿Se me olvidó mencionar que se puede pivotar la representación en cualquier dirección?

 

Y ahora, toda la aplicación.

He añadido la parte ‘server’ con el fin de obtener una visión completa.

Puedes imaginar en qué dirección investigar, ¿verdad? Este último barrio, más grande, más gordo, más alto.

E inmediatamente se puede identificar algunas clases interesantes.

 

Esta gran torre roja es el componente lógico de la flecha verde fino ‘Form’ de la clase de lógica. Tengo curiosidad por ver lo que se esconde detrás de esta entidad lógica.

Un vistazo al código fuente: este componente maneja todos los datos y el procesamiento para el usuario final. Vaya clase. Casi 8 000 líneas de código y:

• Liderando el top 5 de la complejidad: más de 1 200 puntos de CC.
• En cabeza por el código duplicado.
• Y lo más de defectos, incluyendo cuatro bloqueantes.

Tenemos a nuestro campeón.

El plugin City Model no sólo es muy divertido, es también muy útil.

Sonar hace un análisis de las 150 000 líneas de código en menos de 10 minutos. Muy rápido.

En lugar de gastar un par de horas para navegar por los diferentes directorios y tomar notas, puedo hacer un análisis incremental y explorar una representación en 3D del código fuente.

De inmediato se puede identificar las distintas partes para investigar la densidad de cada paquete, la granularidad de los componentes, especialmente los relacionados con la auditoría. Por supuesto, a continuación, buscamos en la lista de defectos para realizar una evaluación más precisa.

El plugin Model City me da una visión general muy útil de la aplicación y me ahorra tiempo y precisión en esa auditoria.

Buen trabajo EXcentia. Un hermoso regalo.

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