Un consultor de Calidad me pregunta si «¿Es posible crear sus propias metricas con Sonar?» y «¿Cúal es la facilidad de introducir nuevas reglas?».

Sé que el está trabajando con un cliente que busca una herramienta de análisis de código. Y este es el criterio típico que se encuentra tradicionalmente en todas las especificaciones cuando se trata de elegir una herramienta de este tipo.

Se ha convertido en una norma universalmente aceptada, incluso hasta el punto de que algunos proveedores de software hacen demostraciones pre-ventas creando una nueva regla en tiempo real. No que sea crítico, pero si que gusta. ¿Te imaginas un vendedor de coches abrir el capó de un vehículo en marcha para ajustar el carburador o rellenar el tanque? Sería espectacular, pero ¿qué interés?

Ya he dicho lo peligroso que es este criterio en este post 8 criterios de elección de una herramienta de análisis de código. Pero no había realmente desarrollado las razones por las que creo que la inclusión de este criterio en la elección de una herramienta puede ser un error.

La cuestión de este consultor (y amigo) es una oportunidad para presentar algunos argumentos a favor de esta tesis, pero sobre todo para:

• Ayudar a los que quieren escoger una herramienta a entender cómo utilizar este criterio.
• Ayudar a los consultores de Calidad a hacer las preguntas necesarias para una mejor definición y evaluación de este criterio, en función del cliente, de su contexto, sus tecnologías, los objetivos, etc..

En resumen, si hay que usar este criterio, tratar de hacerlo inteligentemente y con el conocimiento que nos permitirá obtener el mayor beneficio.

Primero voy a presentar los diferentes tipos de métricas ‘custom’ y luego vamos a ver cómo utilizarlas, en qué tecnologías y con cual coste.

Los diferentes tipos de métricas

Hay todo tipo de métricas, algunas simples, otras más complejas y algunas imposibles. Nota preliminar para los puristas de la Calidad y de la semántica: en aras de la simplicidad, se reunirán en el mismo término de «métricas» diferentes nociones de «reglas», «indicadores», «diagnóstico», etc. Muchas gracias por no formalizarse del vocabulario utilizado. Esto es mi blog, no el Diccionario de la Academia Francesa.

Métricas simples, tipo indicador

Supongamos que quieres medir el número de errores críticos o «Blockers» con el tamaño del código. Una aplicación de 50.000 líneas de código cuenta con 500 defectos críticos: el valor de este indicador, en este ejemplo, será de una violación crítica por cada 100 líneas de código.

En este caso, no hay que hablar de métrica sino de indicador porque este resultado no se consigue directamente del análisis del código, pero de la comparación de dos valores calculados por el análisis. De hecho, no hace falta que la herramienta pueda crear métricas, simplemente necesitamos tener acceso a los resultados del análisis, por lo general por una consulta en la base de datos donde se almacenan estos resultados, o el uso de un servicio web en el caso de Sonar.

Buenas prácticas de programación

Estas métricas miden el uso de sintaxis que violan las buenas prácticas de programación. En todos los lenguajes de desarrollos, algunas instrucciones están prohibidas porque representan un riesgo para el correcto funcionamiento de la aplicación, su rendimiento, la facilidad de mantenimiento y la legibilidad del código, etc. El objetivo de estas métricas es de identificar las sintaxis incorrectas para contar el número de ocurrencias.

Esta suele ser la métrica que se asigna al criterio de “creación de nuevas reglas”, y el caso más utilizado en una demostración. Es relativamente sencillo de realizar este tipo de métrica porque se trata de encontrar una cadena de texto correspondiente a la instrucción prohibida: por ejemplo, «catch (Throwable)» en Java, que no cumple con una buena gestión de errores. O «BREAK» en ABAP que brutalmente interrumpe el programa o su equivalente «STOP … RUN» en Cobol. Un programador puede utilizar estas instrucciones para depuración del código, y luego olvidarse de eliminarlas, con el riesgo de que esta instrucción se ejecuta en un entorno de producción. No conozco ningún «Blockers» más bloqueante.

La búsqueda de una cadena de texto no es muy complicado, pero vamos a considerar todos los casos:

• ‘catch(Throwable xxx)’
• ‘catch (Throwable xxx)’, con un espacio antes del paréntesis o más espacios o una tabulación
• incluso : ‘catch
  (Throwable xxx)’ con un salto de línea antes del paréntesis.

El desarrollo de una tal métrica requiere el uso de expresiones regulares – las famosas RegExp – que no voy a detallar aquí, ya que nunca he sido un experto en ellas.

Sólo quiero decir que incluso una métrica sencilla basada en una única instrucción o una sencilla cadena necesitará un mínimo de reflexión, si no de diseño para identificar a todos los casos posibles, y el control de sintaxis RegExp y un ciclo de pruebas para garantizar que todos los casos están cubiertos.

La mayoría, si no todas las herramientas de análisis de código permiten la creación de métricas de este tipo. Con mayor o menor facilidad por supuesto, pero la facilidad «para introducir una nueva métrica» no es, de hecho, el criterio màs importante porque vamos a pasar la mayor parte del tiempo en el desarrollo y las pruebas de expresiones regulares.

Mi consejo es simplemente identificar las herramientas que realmente ofrecen un proceso poco sencillo para crear nuevas reglas:

• Uso de archivos XML para definir reglas personalizadas y manejar expresiones regulares, archivos necesariamente ubicados en un directorio específico (por lo general no mencionado en la documentación) para que el software les tenga en cuenta.
• Normas de gestión de IDs no automatizadas: cada regla debe tener un identificador único (un número de regla). Hay que administrar los indices de sus propias reglas, y puedes estar seguro de que encontrarás conflictos de identificadores, a veces hasta con los IDs del software cuando se añaden nuevas reglas.
• Programación de tratamientos en la base de datos para contar el número de violaciónes de las reglas que hemos establecido.
• Gestión no automatizada de la métrica en la pantalla o el dashboard: algunas herramientas agrupan métricas por categoría, peso, y hasta por diferentes factores. Entonces, tienes que especificar en qué categoría o qué grupo de métricas deseas que aparezca la métrica.

A continuación en el próximo post, hablaremos de métricas complejas o imposibles.

Hasta luego.

 

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