¿Tiene realmente interés crear sus propias mediciones en una herramienta de análisis de código? ¿Qué beneficios podemos esperar? ¿Qué desventajas, qué obstáculos vamos a encontrar?

Es sorprendente ver cuantas veces se ignoran estas preguntas en una selección de software de análisis de código. Se mide la facilidad o la dificultad para personalizar la herramienta y para crear sus propias reglas en lugar de preguntarse si realmente es necesario.

Esta serie de artículos, por tanto, tiene por objetivo  aclarar estas preguntas para ayudar a definir los criterios adecuados si buscas una herramienta de análisis de código o si eres un consultor de calidad que debe ayudar a un cliente para dicha elección.

Hemos visto anteriormente las métricas más sencillas y en este artículo, vamos a ver métricas más complejas e incluso algunas de las normas o mejores prácticas que encontré en algunos clientes, y que son simplemente imposibles de implementar.

Las métricas complejas

La mayoría de las reglas realmente útiles son complejas, ya que se basan en sintaxis o prácticas de programación complejas, de aplicar, pero en cualquier caso de identificar. Por ejemplo:

• Todas las declaraciones condicionales (tipo ‘IF … THEN … ELSE … ENDIF’) o de bucle (tipoe ‘While … EndWhile’ ou ‘Loop … EndLoop’) se estructuran en bloques multiples : ‘IF’ o ‘While’ y luego varias líneas de código (a veces en más de una página) antes del ‘ENDIF’ o del ‘EndWhile’ de fin de sentencia. Identificar estas instrucciones con una sola RegExp (ver el post anterior sobre las expresiones regulares) se convierte en un verdadero dolor de cabeza. Esta es una fuente bastante común de falsos-positivos.
• Algunas instrucciones pueden necesitar bastante memoria o tiempo de ejecución, sin presentar un riesgo para el rendimiento … a menos que se encuentran en un bucle. Una vez más, identificar la presencia de una sintaxis en un bucle es muy complejo y requiere un conocimiento muy avanzado de las expresiones regulares.
• La mayoría de las reglas de legibilidad y comprensión del código, y entonces de buenas prácticas de mantenibilidad se basan en no añadir estas instrucciones: bucles dentro de bucles, ‘IF’ imbricados, por lo general en varias páginas de código. El riesgo de error y entonces el coste de mantenimiento es más elevado, ya que cualquier modificación de este código requiere un esfuerzo de programación superior. De nuevo, estas reglas son complejas o muy difícil de implementar con las expresiones regulares.
• Otras buenas prácticas de programación dependen del tipo de objetos. El mejor ejemplo de una tal norma, presente en todos los lenguajes y las tecnologías, es la que prohíbe acceder a la base de datos desde la capa de presentación. Probablemente, la regla número uno de seguridad. No es suficiente identificar a una instrucción, sino a todas las diferentes instrucciones con un acceso potencial a la base de datos, y comprobar que se utilizan en una pantalla (capa de presentación) y realizan un procesamiento de base de datos. De hecho, es más sutil y complicado que eso: ejecutar una consulta SQL desde una JSP es estrictamente prohibido, pero pasar la misma consulta a un objeto de la capa de lógica se admite. Una buena práctica es, por supuesto, pasar sólo lo necesario para realizar la consulta SQL a un objeto que se especializa en el acceso a la capa de datos.

Se hace muy difícil e incluso imposible diseñar y implementar esas métricas utilizando RegExp. Por lo general, necesitaremos que la herramienta de análisis de código permite analizar el árbol sintáctico de instrucciones, que no es el caso con todas las herramientas. Y se necesitará también un conocimiento bastante avanzado en la comprensión de este ‘Abstract Syntax Tree’ y de las herramientas y lenguages para examinar este arbol y programar una métrica. No es para novatos.

Las métricas imposibles

Más compleja una métrica, más difícil implementarla, a veces al límite de lo que es posible hacer. Pero unas buenas prácticas personalizadas son simplemente imposibles de automatizar.

Una de las primeras preguntas que hago a un cliente que quiere crear sus propias reglas, es para preguntarle si tiene una lista de normas u otros documentos que describen sus «mejores prácticas». Esto no es siempre el caso, ni siquiera a menudo, pero me alegro si responde de manera afirmativa, ya que significa que la pregunta – fácil o no de implementar una nueva métrica – se justifica.

Leyendo ese documento revela sin embargo que una proporción significativa de estas reglas es simplemente imposible de implementar. Esta proporción es mayor o menor dependiendo de la tecnología (lo veremos en el próximo post sobre este tema). Por ejemplo:

• «Una clase, un método, una función, un procedimiento, un párrafo (COBOL), etc. deben ser documentados» en una plantilla. Ya tratar de definir una expresión regular que comprueba si un comentario está presente en la parte superior de la clase, método, función, etc. es complicado. Ahora construir una expresión regular que verifica que este comentario se refiere a un formato específico, de varias líneas por supuesto, con al menos el autor, la fecha, una descripción del objeto, etc. ¡Buena suerte!
• «La cabecera de cada programa debe incluir una descripción de la funcionalidad implementada.» Esta regla es una versión más avanzada de la anterior: no sólo es necesario verificar que el comentario de cabecera cumpla alguna forma, pero además sea coherente en el plano funcional con los tratamientos del programa. Imposible.
• «Los mensajes de error deben ser traducidos en español, catalán y euskera.» Viva el pluralismo.
• Identificación de código muerto. Me gustan las herramientas de análisis de código que pretenden identificar código muerto. Algo que puede hacer un programador (bastante avanzado) para comentar todo un bloque de código:

IF 1=0

… código muerto

ENDIF

Oh, por supuesto, es muy fácil de definir una expresión regular que encontrará todas las sentencias ‘IF 1 = 0’. ¿Y una RegExp para identificar las ocurrencias de ‘IF A = B’ o ‘IF 1 = 2’ también? Olvídalo.

La próxima vez que un vendedor de software te dice que su software puede identificar código muerto, dale este ejemplo (tratando de no sonreír).

Y yo ni siquiera hablo de normas generales e imprecisas como:

• «Control de sintaxis: hay que corregir los errores críticos y justificar las excepciones a las reglas que no son críticas». Pues adelante.
• «Se prohíbe el desarrollo de una función si ya existe una función que realiza el mismo tratamiento.» Ah, sí, por supuesto, tiene sentido, pero gracias recordarlo.
• «Comprobar que el programa llamado existe». Por acaso. Nota: de hecho, esta regla se puede implementar fácilmente comprobando el código de retorno … cuando existe.

Sólo quiero decir que unas reglas son completamente imposibles de implementar y son más numerosas de lo que piensas (sí, tengo otros ejemplos).

En serio, si su cliente tiene un cuaderno de reglas, mejor no reirse antes de verlo, porque al menos, este documento demuestra que se preocupa por la calidad de sus aplicaciones. Simplemente, la mayoría de estos cuadernos son normas para controles manuales de código, y no se puede simplemente automatizar todas las normas manuales.

Cuando se te pregunta si una herramienta puede crear reglas personalizadas, la primera reacción es exponer lo que esta herramienta puede hacer, y en general con reglas de sintaxis sencilla, como las que vimos en el post anterior. Tu cliente estará contento, pero esto no es la respuesta correcta. Lo que hago:

• Le pregunto si ha definido reglas, es decir, si tiene buenas prácticas que quiere implementar a través de la herramienta.
• Si este es el caso (repuesta afirmativa), le pregunto si estas reglas están documentadas a través de un documento.
• Si este no es el caso (respuesta negativa): le recuerdo que el 100% de los clientes que deseen adquirir una herramienta de análisis de código hacen esta misma pregunta, pero el 90% no lo utilizarán. Y el 90% del 10% restante abandonará la gestión de las métricas personalizadas después de 2 años, porque es demasiado trabajo por muy poco beneficio.
• En todos los demás casos – repuesta indistinta como «lo estamos pensando», «es para saber», «posiblemente», etc. – lo trato como una respuesta negativa (punto anterior), o voy a la pregunta siguiente:

Métricas personalizadas: ¿para que tecnologías?

Este será el tema de nuestro próximo post.

 

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