Hemos visto en el post precedente ‘Casos de uso – Encajar a la perfección‘ cuales casos de uso son aplicados más a menudo con una herramienta de análisis de código, y permiten conseguir el beneficio más alto:

• Quality Gate con el fin de validar la entrega de una nueva versión de una aplicación.
• Gestión de SLAs y benchmarking de proveedores.
• Proceso de Integración / Mejora continúa de los equipos de desarrollo.

Se recomienda combinar estos tres casos de uso para una mejor sinergia y optimizar los resultados. Sin embargo, su aplicación depende de si estás en un contexto de:

• Desarrollo interno: Integración / Mejora Continua + Quality Gate.
• Outsourcing: Quality Gate+ SLA.

¿Cuáles son los métricos más importantes para estos casos de uso?

De hecho, el objetivo en Mejora Continua y SLAs debe quedar sencillo y realista.
Realista significa concretamente: alcanzable. Si pides a tus equipos de desarrollo un resultado perfecto con 50 best practices, esto no es realista. Nadie puede tener 50 medidas diferentes en la cabeza, no se puede conseguir un resultado perfecto en 50 buenas prácticas de programación. Hasta si las conocen, hasta si saben que deben evitar nuevas violaciones de estas reglas de calidad, es imposible recordarlas todas y no puedes evitar la falta de atención ocasional. Y si el objetivo no es alcanzable, el equipo se desanima rápidamente y deja de prestar atención y el proceso será un fracaso.

Establezced un objetivo alcanzable con un mínimo de 10 a 12 reglas, 15 como máximo.

Sencillo significa concretamente: objetivamente medible. Por ejemplo, decides fijar una meta para alcanzar el 99,99% de calidad. Sin embargo, el 99,99% de qué? El número de líneas de código? El número de objetos incluidos? Imaginamos una regla (clásica) de gestión de excepciones que un ‘throw’ Java no debería estar vacío. Obviamente, sólo se aplica a los métodos que implementan una lógica de negocio. Si una clase tiene 100 setters o getters sin ninguna lógica de negocio, se aplica la regla? Si esta clase cuenta con 200 líneas de código o más, vas a incluir estas líneas en tu cálculo? No sólo esto se vuelve complicado, pero además, penalizará a los desarrolladores que tienen una clase con 20 métodos que implementarán un ‘throw’: basta con olvida uno para alcanzar el 5 % de error.

El objetivo más sencillo y más fácilmente medible es: 0 defecto. No se tolera ninguna negligencia, cualquiera sea el número de líneas, los métodos, clases, etc.
Pues 10 o 12 métricas con una tolerancia 0.

¿Y cuáles son las reglas más importantes para las cuales no aceptaremos ningún defecto? Las que constituyen un error crítico en términos de desarrollo, porque el impacto sobre el comportamiento de la aplicación y para el usuario final será crítico. Una mala gestión de los errores puede acabar en una página blanca para el usuario o una página de error incomprensible, la interrupción del tratamiento, una transacción no finalizada, incluso una corrupción de datos.

Lo mismo ocurre con la utilización de ciertas clases genéricas que no permiten especializar una excepción y comprender y trazar el error sobrevenido. También, ciertas sintaxis que pueden revelarse peligrosas en materia de corrupción de datos y de seguridad.

Cobol y ABAP no conocen el concepto de clases o métodos, pero los principios siguen siendo los mismos: siempre utilizar un código de retorno cuando se llama a una función o un procesamiento de una base de datos, evitar las instrucciones que interrumpen el procesamiento como Break o Stop Run. Estas tecnologías son también muy sensibles al rendimiento por lo que puedes añadir todos los tratamientos costosos en el SQL y / o en bucles.

Favoreceremos pues métricas tales como:

• Java : Empty Try block, Empty Finally block, Empty If statement, Empty While Statement, Illegal throws (java.lang.error, java.lang.RuntimeException), Equals HashCode, Array stored directly, …
• Cobol, Abap : If without Endif, Others in Case, When Other in Evaluate, Break, Stop Run, Sort, Select *, Select Distinct, Group by, Select in Select, Cursor inside a loop, Open/Close in a loop, …

Estas reglas tienen la ventaja de ser igualmente aceptables dentro de un SLA para un proveedor y un objetivo de 0 defecto es fácilmente medible.

Ahora ¿qué pasa con las reglas para aceptar o rechazar una versión de aplicación en una Quality Gate? En primer lugar vamos a incluir las métricas anteriores, lógicamente: si la regla de 0 defecto se aplica a nivel de los desarrolladores, no queremos encontrar estos defectos en la aplicación, que el equipo sea interno o externo.

También se incluyen algunas medidas de mantenimiento, es decir, indicadores que miden la calidad del código en términos de costes de mantenimiento.

Imaginemos una aplicación J2EE con 500 clases con un promedio de 20 métodos, es decir 1 000 métodos en total. Suponemos que un código Java de calidad pueda contar 7.5 % de objetos complejos y 2.5 % de objetos muy complejos, pues 750 métodos complejos y 250 métodos muy complejos en nuestro ejemplo. Este código es el más costoso a evolucionar porque es difícil de comprender, y también más peligroso ya que el riesgo de introducir un defecto en caso de modificación es más elevado.

Imaginemos ahora qué el equipo de proyecto añade 5 % de métodos complejos y muy complejos a cada versión. Esta cifra es bastante limitada, esto representa sólo una docena de métodos muy complejos para los 250 existentes. A razón de 4 versiones al año, el total de las reglas más complejas habrá aumentado más de 20 % y la complejidad de la aplicación habrá doblado en menos de 4 años. Sabiendo el impacto de esta complejidad sobre tus presupuestos, tus planificaciones y el número de bugs para los usuarios, comprendemos rápidamente por qué es recomendable vigilar toda deriva en este campo.

Podremos pues añadir este tipo de métricas en un SLA y luego en un Quality Gate, y otras medidas que impactan la mantenibilidad tales como el % de código duplicado, el % de código en comentarios (Commented-out LOC), y si la herramienta sabe calcularlo, Technical Debt (habrá que tomar en consideración el aumento de la talla del código para esta medida). Y el % de comentarios cuando el código es desarrollado por un proveedor.

Evidentemente, es aconsejado verificar estas métricas lo antes posible, lo que supone aplicarlas en un proceso de Integración Continua. Sin embargo, no recomiendo política ‘0 defecto’ a este nivel: lo importante es llegar a Quality Gate sin ningún objeto nuevo complejo, no suprimirlos sistemáticamente de todo ‘build’. Mejor dejar un margen de maniobra, para no decir autonomía, al equipo de proyecto en este campo. Sin embargo es importante sensibilizar sobre estas reglas, de las que sacan provecho.

Tenga en cuenta que los errores que representan un riesgo para el usuario también pueden impactar fuertemente los costes de mantenimiento de la aplicación. Una mala gestión de los errores significa un tiempo de detección de bugs y de corrección bastante elevado.

No pretendemos elegir las 10 a 20 métricas más importantes, sino dar un ejemplo para estos tres casos de uso. Puedes constituir tu propia lista según tus propios criterios: las tecnologías utilizadas para tus aplicaciones, el nivel de madurez de sus equipos, la alineación oficio/TI (ver ‘¿Cual es la primera pregunta?‘), si el código es desarrollado internamente o por un proveedor, etc.

Las 10 a 20 métricas más importantes son las que te permitirán mejorar la calidad de tus aplicaciones sacando el máximo de beneficios de estos tres casos de usos.

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