Complejidad ciclomática, o la métrica esencial para evaluar el diseño software
Fue en 1976 cuando Thomas McCabe publicó un artículo en el que argumentaba como la complejidad del código puede obtenerse desde su flujo de control, o dicho de una manera más exhaustiva del número de rutas linealmente independientes del código, definiendo para ello una de las métricas más útiles en ingeniería del software, y que denominó “complejidad ciclomática”. En sí el concepto no era nuevo, ya que supone la adaptación de la prueba general de compresibilidad de Flesch-Kincaid (que suena raro pero es bastante conocida en mediciones de la comprensibilidad de un texto), pero supuso una gran aportación al diseño software. No voy a entrar en su cálculo, ya que hay numerosos sitios donde lo explican.
Y ¿Por qué es tan importante y aún la citamos?
- Permite apreciar la calidad del diseño software, de una manera rápida y con independencia del tamaño de la aplicación. Es una medida esencial cuando necesitas “tomar la temperatura” de un diseño software (más si estás realizando una auditoría externa y no conocías de antes la aplicación) de un tamaño considerable, y que se puede obtener fácilmente y de manera automatizada (ver aquí, además los PMD, etc., la obtienen fácilmente).
- También la hemos utilizado para planificar proyectos de mejora de grandes productos software, para priorizar las partes del diseño a mejorar.
- Por otro lado, en muchas ocasiones, es base para calcular el valor de las mejoras del diseño, o el valor que aporta introducir un patrón o buena práctica.
- Y, además, nos da el número de casos de prueba unitarios básicos para obtener una cobertura del 100%.
- También una aproximación al grado de comprensibilidad del diseño.
De manera general es un síntoma que nos ayuda a determinar muchas de las posibles enfermedades del software, como sobre coste de realizar evolutivos debido a la rigidez del diseño, carencias modulares del diseño, diseños estructurados en entornos orientados a objetos, etc. Existe una relación entre el esfuerzo (horas – hombre, coste) necesario para mantener la aplicación y la complejidad de su diseño.