Medir la calidad del código: qué métricas son fiables y cuáles solo tranquilizan

La calidad del código no se puede expresar con un solo número. La medición solo se vuelve fiable cuando usted observa cuatro cosas a la vez: la cobertura de pruebas de las líneas modificadas, la proporción de duplicados, la frecuencia de cambio de los archivos de riesgo y el tiempo hasta corregir un error. La norma internacional de referencia es ISO/IEC 25010:2023.

¿Qué es, en realidad, la calidad del código?

La calidad del código no es un adjetivo, sino un modelo compuesto por varias características. La norma de referencia es ISO/IEC 25010:2023, parte de la familia SQuaRE. La versión revisada en 2023 describe nueve características de calidad del producto.

La novedad respecto a la versión anterior es la característica Safety (seguridad funcional), con subcaracterísticas como la detección de riesgos, el estado seguro ante fallos y la advertencia de peligros. Además, Usability y Portability fueron sustituidas por Interaction Capability y Flexibility; el antiguo modelo «Quality in Use» se encuentra desde 2023 en su propia norma, ISO/IEC 25019.

Para el trabajo diario, la norma es demasiado general para medir directamente. Aun así es útil, porque estructura la discusión: cuando alguien exige «mejor calidad», basta un vistazo a las nueve características para aclarar en dos minutos a cuál se refiere.

¿Qué métricas dicen realmente algo?

Cuatro, y solo funcionan juntas. Cada una por separado puede manipularse sin que la calidad mejore.

¿Por qué la cobertura de pruebas por sí sola induce a error?

Porque cuenta qué líneas se ejecutaron, no qué comportamiento se verificó. Una prueba que llama a una función y no comprueba nada produce el cien por cien de cobertura para esa función y cero conocimiento.

En las pruebas generadas por IA, esto es más que una objeción teórica. Un modelo que escribe pruebas para código existente deduce los valores esperados del comportamiento de ese código. Si el código contiene un error, el error se convierte en aserción. La prueba está en verde y protege el error.

Dos antídotos: primero, medir la cobertura de las líneas modificadas en lugar de la cobertura total: el valor total se diluye y apenas se mueve. Segundo, ejecutar de vez en cuando pruebas de mutación: modifican el código a propósito y comprueban si al menos una prueba lo detecta. Es el único método extendido que mide la calidad de las propias pruebas. Más información en cobertura de pruebas en código de IA.

¿Cómo introducir métricas de calidad sin desmotivar al equipo?

Aplicando las métricas a los cambios y no a las personas, y fijando umbrales para lo nuevo y no para lo existente.

• Sin métricas de personas. Líneas por desarrollador, número de commits, errores encontrados por revisor: todo eso genera un comportamiento que mejora el número y no el producto.
• Congelar lo existente, endurecer lo nuevo. El código heredado se queda como está; el umbral rige para las líneas nuevas y modificadas. Así cada cambio se convierte en una pequeña mejora, sin que nadie tenga que financiar una limpieza general.
• Evolución en lugar de instantánea. Una proporción de duplicados del nueve por ciento carece de significado sin una dirección.
• Pocos números. Cuatro métricas se leen. Veinte se convierten en un informe que nadie abre.

¿Qué métricas son especialmente importantes para el desarrollo asistido por IA?

La proporción de duplicados y el crecimiento de dependencias: ambas reaccionan directamente a los patrones típicos del código generado.

Para la proporción de duplicados, el análisis de GitClear aporta la justificación: tanto los bloques duplicados como el código copiado han aumentado claramente desde 2022. Quien solo mide la cobertura de pruebas no ve este movimiento: ocurre entre archivos, no dentro de ellos.

El crecimiento de dependencias es el segundo punto ciego: una herramienta que añade paquetes de paso modifica su superficie de ataque y su situación de licencias sin activar una sola de las métricas que se suelen vigilar.

Preguntas frecuentes sobre métricas de calidad

¿Qué cobertura de pruebas es buena?

No existe una cifra objetivo universal, y cualquier porcentaje que se cite es una convención, no una norma. Una regla más sólida: el código nuevo y modificado no debería quedar por debajo de la cobertura existente del proyecto. Así el valor sube por sí solo, sin un límite arbitrario.

¿Cuál es la diferencia entre ISO 25010 e ISO 25019?

ISO/IEC 25010:2023 describe la calidad del producto, es decir, las propiedades del software en sí. El antiguo modelo «Quality in Use», la calidad desde el punto de vista del uso, se trasladó a ISO/IEC 25019 con la revisión de 2023.

¿Necesito para esto una herramienta como SonarQube?

No necesariamente. La proporción de duplicados y la complejidad también las ofrecen herramientas de análisis libres, y la frecuencia de cambio la proporciona el propio Git. Una plataforma compensa sobre todo por la evolución histórica y la lógica de umbrales: para eso se acuñó el término Quality Gate, véase Qué es un Quality Gate.

¿Con qué frecuencia debe medirse?

De forma automática en cada cambio, con una revisión una vez al mes. Mirar con más frecuencia genera ruido; con menos, se pierden las tendencias.

Se mide rápido, se actúa pocas veces. Code Guardian cierra esta brecha: el resultado de un cambio no se afirma, sino que se demuestra, con la salida de la comprobación y no con la promesa de que se ha comprobado.

Fuentes

• ISO/IEC 25010:2023, Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model (nueve características, novedad: Safety; Quality in Use trasladado a ISO/IEC 25019).
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.

Fecha: 27 de julio de 2026. Valoración técnica de carácter general. Las citas de normas reflejan su estructura y no sustituyen la adquisición de la norma.