Siguiendo con nuestra serie sobre fabricación ecoLógica, en este artículo analizamos el Control de la Calidad Software mediante la inspección de código continua . En este caso, buscamos como objetivo minimizar la deuda técnica, reforzando el valor añadido de cada entrega.

En particular, la deuda técnica en la que más nos centramos en Panel Sistemas es la generada inconscientemente (inadvertida), porque para la deuda generada «c o n s c i e n t e m e n t e» ya tenemos los controles establecidos por nuestra metodología OGMA. Para mi, la deuda técnica que más me desagrada es la generada desde la arquitectura software (por su amplio impacto) y la que más me aburre es la asociada al código duplicado (por motivos obvios).

Si queréis iniciaros sobre la deuda técnica, su definición o su contabilidad, os recomendamos los artículos de Javier Garzas. Siguiendo sus liturgias, trazamos la evolución de evidencias asociadas a la calidad software, resaltando especialmente la complejidad ciclomática y el código duplicado.

¡Cuidado! No hay que confiarse. Aunque tengamos «contabilizados» los componentes de la deuda técnica, si estos no están basados en principios de diseño «simples» (KISS, DRY, Navaja de Ockham, etc), SOLIDos, con bajo acoplamiento y alta cohesión, nuestra capacidad real de mejora está muy limitada. En resumen, como diría el «Tío Bob» mantén tu código limpio.

Afortunadamente, las prácticas de inspección continua de código nos permitirán conocer en todo momento la solidez de nuestros cimientos.

Recuerda que
sin inspección de código continua
no hay integración o entrega continua que valga.

Como bien proclama Antonio Manuel Muñiz, gracias a la inspección de código continua conseguiremos que los equipos de trabajo tengan un conocimiento objetivo, unificado y compartido del estado del proyecto. Pregunta: ¿qué es un conocimiento «objetivo»? El derivado de la adherencia a las buenas prácticas  de la compañía, con métricas y líneas de mejora.

Claro que siempre hay opiniones … 😉

En nuestro día a día, disponer de este servicio de «revisión médica abierto 24 horas», se ha convertido -definitivamente- en una prestación sin la que no concebimos ya el proceso de construcción de software.

Concretando, para la inspección de código continua utilizamos SonarQube y para la recurrencia nos apoyamos en Jenkins, todo ello cortesía de nuestro ecosistema de fabricación ecoLógica (Clinker).

A continuación, detallamos las facilidades que nos presta Sonar en las tareas de inspección para la medida de la calidad estática y dinámica del software generado. Finalmente, la repetición sistemática de las medidas, su seguimiento y análisis nos permitirán subir de nivel en nuestro trabajo.

Las métricas e indicadores que SonarQube nos permite tener monitorizados son:

• Guía de estilo de codificación unificada (CheckStyle).
• Mantener un código fuente más elegante, sencillo, optimizado y mantenible (PMD).
• Anticiparte a defectos potenciales (Findbugs).
• Tener controlado el código duplicado (CPD).
• Detectar incompatibilidades por cambios en la API pública, cambios de versión, etc (Clirr).

Durante la fase de puesta en marcha de este servicio de inspección de código continua, nos apoyamos en proyectos propios consolidados para afinar la configuración de las reglas a aplicar a nivel organizacional. Una vez que ya tenemos consensuadas las reglas a utilizar, estamos siguiendo un ciclo calidad software muy sencillo:

• Bienvenida: se trata de una inspección de entrada que se aplica a los proyectos heredados y nos permite catalogar el código recibido. Es la base para los compromisos de nivel de calidad (QLA).
• Seguimiento: aplicando los principios de inspección de código continua diaria, se realimenta el cuadro de mandos de control. Nos permite ir analizando la deuda técnica generada, evaluar su impacto, calcular el ROI de su resolución para, por último, aplicar acciones correctivas que la mitiguen.
• Certificación: cada vez que se cierra una fase, se audita la calidad del código y se registra como nivel de salida.

La forma más sencilla de iniciar estos ciclos es lanzar tareas de inspección sobre nuestro sistema de control de versiones con una cadencia controlada, apoyándonos en herramienta de software para la gestión y construcción de proyectos consolidados.

En el caso de proyectos basados en C y C++ nos estamos apoyando en SonarQube Runner. Nos parece muy importante destacar la facilidad de escalado de la herramienta, con un amplio abanico de lenguajes de programación a utilizar, la sencillez de uso y la continua evolución en nuevas funcionalidades que no tienen nada que envidiar a las herramientas comerciales.

En nuestro caso particular nos ha permitido con un bajo coste tener un entrenador personal a plena disposición, permitiéndonos aprender día a día, anticiparnos a bugs potenciales antes de la finalización de cada entrega (Sprint), detectar problemas de optimización, tener indicadores objetivos de dónde debemos refactorizar nuestro código, medir el índice de cobertura, y tener un estilo de codificación unificado… Además de descargar a nuestro IDE de estas tareas, mejorando el rendimiento de nuestras estaciones de trabajo y delegando las tareas en nuestro ecosistema software de cabecera.

Por último,  sólo recordaros nuestro decálogo para la fabricación de software:

• Mantén controlada tu deuda técnica, es posible que en el futuro no seas capaz de pagar los intereses que genera  – Responsabilidad.
• No improvises … sistemáticamente,  institucionaliza las reglas aplicadas a todos los proyectos – Institucionaliza.
• Descarga a las personas y a tu estación de trabajo de trabajos repetitivos – Automatiza.
• Aprende y aplica lo que aprendes – Conocimiento reutilizable.
• Cuida la maquinaria, te va la vida – Clinker by Klicap.

Para un próximo post, espero contaros una experiencia real con alguno de nuestros proyectos concretos 😉

 ——————————————————————————————————————–