Último artículo de nuestra serie sobre la creación de métricas personalizadas.

Vamos a ver los diferentes costes asociados a la personalización de las métricas, que son generalmente mal identificados o completamente ignorados en un proyecto de adquisición de una herramienta de análisis de código.

Terminaremos con un resumen de todas las diferentes preguntas que hacer – o pedir a un cliente – para determinar si la creación de métricas personalizadas es realmente un criterio para la elección de una herramienta de este tipo.  

Costes ocultos

Coste de implantación

Un cliente suele hacer la pregunta «¿Es fácil crear nuevas métricas con esta herramienta?» o «¿Cuál es la dificultad?», pero no «¿Cuál es el coste de gestionar mis propias métricas?». Sin embargo, hay diferentes costes de diferentes tipos.

En primer lugar, hay un coste para la creación de métricas. Obviamente, los editores de software no lo dicen, pero se centran en ocultarlos con una brillante demostración de creación de una nueva regla. Pero más a menudo será una métrica sencilla y no una regla compleja. Y como lo hemos visto en el tercer artículo de esta serie, dedicado a la personalización de métricas por tecnología, son estas reglas complejas que son las más útiles y las más numerosas.

Pues, contrariamente a lo que a menudo se quiere creer, una nueva métrica no se realiza con un chasqueo de dedos, sino que requiere un mínimo de reflexión, por no decir, de diseño:

• ¿Quieres identificar en el código una violación a una buena práctica de programación?
  • ¿Y en este caso, se trata de una instrucción identificada por una cadena única o más bien un compuesto de sentencias del tipo ‘IF … THEN … ELSE … ENDIF’?
• ¿Lo que piensas implementar es una regla de arquitectura (tipo framework), como lo hemosvisto en el tercero post de esta serie?

Incluso para una métrica sencilla basada en una sentencia única, se debe pensar en todas las posibles expresiones o formas de usarla. Por ejemplo, un catch() se puede escribir con un espacio o no antes del paréntesis, y a veces, lo que parece un espacio es en realidad una tabulación. Incluso se puede escribir en más de una línea.

Incluso para una métrica sencilla, necesitamos pensarlo un poco para construir la expresión regular, la famosa RegExp y probablemente múltiples ensayos. Créame, solamente en una demo funciona esto funciona la primera vez!

Así que puedes imaginar que para una sentencia compuesta, se vuelve mucho más complicado. Y hay un montón de reglas que combinan varias instrucciones, tales como las reglas de estructuración del código, con declaraciones anidadas (un IF dentro de un IF dentro de un IF, etc.), o violaciones de las mejores prácticas de rendimiento con instrucciones peligrosas cuando se encuentran en un bucle (creación de objetos por ejemplo).

Y solamente hemos hablado de la identificación del código específico a una métrica a través de una expresión regular. Si tienes que navegar dentro de un árbol de sintaxis, será más complicado. Si tienes que programar una regla de arquitectura, será más complicado. En la mayoría de los casos, siempre es más complicado.

El desarrollo de una nueva métrica no se termina siempre con la identificación de instrucciones dentro de un archivo, también puede ser necesario programar el cálculo de los resultados, la visualización de la métrica en el cuadro de mando, o otro tipo de cálculo requerido por el software. Una herramienta mide la calidad con el el porcentaje de violaciones en comparación con todas las instrucciones del mismo tipo. Por ejemplo, un catch() vació no es una buena práctica. Si quieres implementar una métrica de este tipo, necesitarás medir cuantos catch() vacíos se encuentran en todos los catch() de la aplicación, para que la métrica aparezca correctamente en el dashboard.

Por último, todas las herramientas necesitan categorizar cualquier métrica sobre un eje de gravedad – de Minor a Critical o Blocker. Algunas herramientas también requieren que se especifiquen parámetros adicionales, por ejemplo, donde se encuentra la regla en el modelo ‘calimétrico’, dependiendo de si afecta el mantenimiento, o el rendimiento, la fiabilidad, etc. Estos parámetros se pueden guardar en un fichero, o en la base de datos, pero hay que definirlos correctamente, con el ID correcto de la métrica, no equivocarse, comprobar que se visualiza bien en la pantalla con el resultado esperado, etc.

Lo que quiero decir es que la creación de métricas personalizadas debe abordarse como un proyecto con:

• Una fase de diseño: ¿cuáles son los parámetros que deseas desarrollar? ¿Están documentadas en un cuaderno de reglas o cualquier otro documento? ¿Cuáles son los diferentes casos, las diferentes sintaxis posibles, la expresión regular correspondiente, etc.
• Una fase de desarrollo: escribir la RegExp o la programación de la navegación en el árbol de análisis, y un mínimo de pruebas unitarias.
• Una fase de control de calidad, con casos de pruebas que cubren todos los casos posibles identificados previamente, combinando varias instancias de la misma instrucción en el mismo programa, la verificación de los resultados – contar las violaciones, comprobar e identificar posibles falsos positivos – y como aparece en el dashboard.

Costes de mantenimiento

El coste de desarrollo de reglas personalizadas puede llegar rápidamente a varias decenas de días-hombre. Pero hay otros costes posteriores.

El primero, que es el más frecuente, pero que a menudo no se piensa: ¿qué pasará cuando se instalará una nueva versión del software de análisis de código? Has hecho un desarrollo, que se guarda necesariamente en algún lugar: unos archivos, un directorio, un repositorio, una base de datos, etc.

Por ejemplo, la expresión regular se define en un archivo XML localizado en un directorio determinado, así como en una tabla en la base de datos, con un procedimiento almacenado para calcular los resultados. Bueno, ¿qué sucede cuando se actualiza el software? La nueva versión guarda los archivos xml en el directorio o hay que reinstalarlos después? ¿O hay que añadir nuestras métricas en un fichero que viene con la nueva versión para poder usarlas con las nuevas métricas entregadas en la nueva versión?

¿Debes importar y volver a aplicar el procedimiento almacenado? ¿Debes importar tu propio modelo ‘cualimétrico’ con la definición de tus propias reglas para que aparezcan en la interfaz de la nueva versión?

Otro tipo de coste de mantenimiento: el software ha cambiado y tu desarrollo ya no funciona. Sí, el modo de gestión de las métricas puede, y sin duda va a cambiar con el tiempo. Tendrás que adaptar tu «paquete» de métricas para adaptarlo. Coste de mantenimiento evolutivo.

También se puede ocurrir errores. Por ejemplo, debes especificar un número o ID para cada una de tus métricas y, mala suerte, la nueva versión del software implementa nuevas métricas que utilizan estos identificadores. Tus reglas no aparecen en la nueva versión del cuadro de mando y debes averiguar por qué, y luego hacer cambios con el fin de resolver este conflicto de IDs. Coste de mantenimiento correctivo.

Esto significa que tendrás que gestionar tus desarrollos en versiones. He visto clientes muy descontentos porque encontraban regresiones en sus métricas después de instalar una nueva versión del software, cuando en realidad habían instalado una versión anterior de sus normas en la que no todavía no estaban presentes esas métricas. Y en un tal caso, se necesita tiempo para investigar e identificar el origen de la llamada «regresión».

Por último, para evitar esto, lo mejor es poner a prueba de manera sistemática y profunda la nueva versión con sus propias reglas. Esto significa definir y documentar y realizar algunos procedimientos de pruebas (además de la documentación del proceso de actualización del software, la gestión de versiones de tu «paquete» de normas, etc.).

Así que, básicamente, he incluido en la misma categoría de costes de mantenimiento todo tipo de costes de actualización, correcciones y cambios, pruebas, documentación, etc. Sin embargo, es importante identificarlos desde el principio pues, como se puede ver, no son ligeras.

Las preguntas

La creación de métricas personalizadas sólo se justifica si existe una necesidad real e bastante importante. Pues que sea fácil crearlas no debe ser un criterio para la selección de una herramienta de análisis de código. A lo mejor, es solamente un ‘plus’.

Si quieres comprar una bicicleta, y puedes permitirte una bicicleta de alta gama, con un cuadro en titanio, una horquilla en carbono, 15 velocidades y ruedas ‘tubeless’. Pero si solamente tienes la intención de usarla para ir de compras, no será lo más práctico, y el precio será muy superior a los beneficios que podrás conseguir. A menos que tu intención es hacerte feliz, por supuesto.

Por desgracia, esto es a menudo el caso, y por lo tanto es difícil hacer que alguien renuncia cuando ha decidido hacerse un regalo. Es nuestro trabajo como consultor de comprobar la existencia real de una necesidad y medir los costes ocultos. Así que las preguntas:

• ¿Tiene usted normas de calidad y buenas prácticas que desea automatizar? Si no, yo no puedo imaginar realmente un caso que justifica crear sus propios indicadores.

Muy a menudo, la repuesta será ‘No pero …’ seguida de un intento de justificarse con argumentos no muy precisos. Hay que defender su pequeño capricho. En este caso, le recuerdo que el 90% de los usuarios de una herramienta de análisis de código usan las reglas existentes, y el 90% del 10% que desarrollan sus propias métricas las abandonan después de dos años.

• ¿Qué tipo de métrica?

Tuve un cliente que quería absolutamente las métricas de Halstead. Estas medidas cuentan el número de operandos y / o de operadores, tal como una medida de la complejidad. Otras veces, se requiere los índices de mantenimiento del SEI (combinación de indicadores como el número de líneas de código, la complejidad ciclomática, la tasa de comentarios …).

Estas métricas son obsoletas, por lo que la mayoría de las herramientas de análisis de código no las ofrecen más. ¿Por qué invertir en la creación de este tipo de métricas, mientras que las existentes son más relevantes? ¿Por qué añadir carga en el uso de una herramienta, la lectura de un cuadro de mando y la interpretación de los resultados con mediciones imprecisas?

También están aquellos que no son satisfechos con la catégorias de métricas ‘Critical’ o ‘Blockers’, y desean crear una categoría especial para ellos, algo así como ‘super-extra-blockers’. Esto lo llamo yo el síndrome de Spinal Tap: This one goes to eleven.

• ¿Qué tecnologías?

Como visto en el post anterior, es en el campo de las aplicaciones de SAP que se encontrará muy a menudo una necesidad real. En el mundo de las nuevas tecnologías. J2EE, NET, etc. ya hay suficientes normas para no crear nuevas, salvo el caso particular de los frameworks propietarios.

• ¿Qué porcentaje del portafolio de aplicaciones para esa tecnología?

Siempre hay clientes que quieren métricas para lenguajes poco comunes o antiguos: PL1, Pacbase, Informix, Fortran, etc. Incluso tienen a menudo una lista de reglas que utilizan para realizar controles manuales. Pues si, es una necesidad real, pero las aplicaciones desarrolladas en esos idiomas rara vez representan más del 10% del portafolio de las aplicaciones, son por lo general bastante antiguas, probadas, no conocen tantos cambios, etc.

• ¿Tiene una lista de reglas u otra documentación de ellas?

Si no es el caso, dudo mucho que estas normas se apliquen.

Si tienes una necesidad real de métricas personalizadas, si debes elegir una herramienta de análisis de código basándote en este criterio de creación y gestión de métricas personalizadas, entonces es muy importante identificar con precisión:

• ¿Cuáles son los diferentes pasos necesarios para crear una métrica?
• ¿Qué la herramienta de análisis de código sabe hacer de forma automática?
• Lo que no sabe hacer: te toca a ti.
• ¿Cuáles son las diferentes acciones que se deben realizar en caso de actualización de la versión del software?

De los 3 o 4 softwares que has elegido en ‘short-list’, prepara una prueba, como un piloto con unos casos:

• Desarrollo de un indicador del tipo métrica sencilla. Por ejemplo, poder introducir el coste del proyecto  o el número de días para realizar la última versión o el número de personas en el equipo del proyecto, y lo dividir por el número de errores de tipo Blockers o Critical o Major.
• Desarrollo de una métrica sencilla de tipo buena práctica de programación. Por ejemplo, identificar todas las instrucciones write() y writeln() – vamos a decir que ellas se prohíban en favor de un sistema de mensajes desarrollado ‘en casa’. Prepara algunos archivos de prueba con casos bien retorcidos con espacios o saltos de línea entre diferentes de estas instrucciones y sus parámetros.
• Desarrollo de una métrica compleja: identificar las instrucciones anteriores write() y writeln() en un bucle. Una vez más, imagina unas pruebas muy complejas con bucles dentro de bucles en varias páginas, por ejemplo.
• Actualización de versión: pide a cada proveedor de software para un paquete con los ficheros resultantes del desarrollo de las tres reglas anteriores, con una documentación de su instalación o actualización. Haz una actualización de la versión (o volver a instalar la versión actual) con la documentación para instalar el paquete, paso a paso, y medir la complejidad del procedimiento.

La creación de métricas personalizadas no es un criterio para la elección de una herramienta de análisis de código si no tienes una necesidad real. Si este es el caso, entonces tratar este criterio con el máximo profesionalismo e identificar los costes ocultos. No te conforma con una demostración del proveedor, haz un piloto, pon a contribución el editor del software. Si lo necesitas, pide asistencia de un consultor de Calidad especializado en estos temas y esas herramientas.

Si quieres comprar una bicicleta de carreras, claro que la vas a probar. No vas a pedir al vendedor si es fácil para pedalear o cambiar la rueda.

 

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