Las métricas de complejidad de tareas en el desarrollo de software responden a una pregunta que todo equipo de entrega se plantea varias veces por semana: ¿cuánto cuesta realmente este trabajo? Un ticket que parece un cambio de dos días puede ocultar una función con cuarenta ramas, tres integraciones externas y ninguna prueba. Sin una forma compartida de medir la complejidad, las estimaciones se desvían, los defectos se concentran en los mismos módulos y nadie sabe explicar por qué la última funcionalidad «pequeña» llevó un mes.
Para los fundadores y CTO que contratan o dirigen capacidad de ingeniería, la complejidad también es una señal de coste. El código muy complejo es más lento de cambiar, más difícil de probar y más propenso a fallar, por lo que encarece en silencio cada funcionalidad futura. Los equipos que ofrecen servicios de product engineering con quality gates integrados tratan la complejidad como una propiedad medida del código y del backlog, no como una opinión expresada en el sprint planning.
Esta guía cubre las dos caras del problema. Explica las métricas de complejidad de código que ofrecen las herramientas de análisis estático, las medidas de tarea que los equipos usan para dimensionar el trabajo, cómo realizar paso a paso un análisis de complejidad de tareas, qué umbrales son razonables, qué herramientas usar y cómo cambian el panorama los asistentes de código con IA en 2026. Se basa en investigaciones publicadas de McCabe, Halstead, SonarSource e IFPUG y en lo que vemos al dirigir equipos de entrega para clientes de EE. UU. y la UE.
¿Qué son las métricas de complejidad de tareas en el desarrollo de software?
Las métricas de complejidad de tareas en el desarrollo de software son medidas cuantitativas de lo difícil que es comprender, implementar, probar y mantener una unidad de trabajo. Van desde métricas de código calculadas automáticamente a partir del código fuente hasta medidas de tarea que el equipo asigna al planificar y estimar el trabajo.
Complejidad no es lo mismo que tamaño. Un archivo de configuración de 300 líneas puede ser trivial, mientras que una función de precios de 40 líneas con condiciones anidadas, zonas horarias y reglas de divisas puede ser el código más arriesgado del sistema. Las buenas métricas de complejidad recogen el número de decisiones, rutas, dependencias e incógnitas, no solo el volumen de código.
Complejidad a nivel de código frente a nivel de tarea
La complejidad a nivel de código describe el código fuente existente o resultante, mientras que la complejidad a nivel de tarea describe el trabajo necesario para cambiarlo. Ambas están relacionadas, pero responden a preguntas distintas.
- Las métricas de código, como la complejidad ciclomática, la complejidad cognitiva, las medidas de Halstead, el índice de mantenibilidad y el acoplamiento, las calculan las herramientas a partir del propio código. Son objetivas y repetibles, pero solo ven lo que ya está escrito.
- Las medidas de tarea, como los story points, los puntos de función y las listas de factores de complejidad, se asignan antes de empezar el trabajo. Incluyen lo que las métricas de código no pueden ver: requisitos poco claros, dependencias de terceros, tecnologías nuevas y restricciones regulatorias.
Un análisis útil de la complejidad de tareas combina ambas: las métricas de código le indican lo arriesgada que es la zona que va a tocar, y las medidas de tarea le indican cuánta incertidumbre conlleva el propio cambio.
¿Por qué debería medir la complejidad de las tareas?
Debería medir la complejidad de las tareas porque es uno de los mejores predictores del esfuerzo, los defectos y el coste de mantenimiento, y porque hace visible el riesgo oculto antes de que llegue a producción. La complejidad medida convierte «esto parece difícil» en un dato del que todo el equipo puede hablar.
- Estimaciones más honestas: saber que un ticket toca un módulo con alta complejidad ciclomática y cambios frecuentes explica por qué necesita más tiempo y más pruebas.
- Pruebas dirigidas: la complejidad ciclomática indica el número mínimo de casos de prueba necesarios para cubrir cada ruta independiente de una función.
- Prevención de defectos: los defectos se concentran en archivos complejos y modificados con frecuencia, por lo que los datos de complejidad muestran dónde importan más la revisión de código y las pruebas.
- Prioridades de refactorización: la complejidad combinada con la frecuencia de cambio identifica los hotspots donde la limpieza se amortiza antes.
- Incorporación más rápida: un código más simple y bien estructurado permite a los nuevos desarrolladores contribuir con seguridad en días en lugar de semanas.
- Supervisión de proveedores: las tendencias de complejidad en la CI ofrecen a los responsables no técnicos una visión objetiva de si un código interno o externalizado se vuelve más sano o más frágil.
¿Qué métricas de complejidad de código importan más?
Las métricas de complejidad de código que más importan en 2026 son la complejidad ciclomática, la complejidad cognitiva, el volumen de Halstead, el índice de mantenibilidad, el acoplamiento y la profundidad de herencia, y el churn del código combinado en hotspots. En conjunto describen cuántas rutas tiene una función, lo difícil que es leerla, cuánto depende de otro código y con qué frecuencia cambia.
| Métrica | Qué mide | Cómo se calcula | Umbral habitual |
|---|---|---|---|
| Complejidad ciclomática | Número de rutas independientes de una función | Puntos de decisión + 1 (McCabe, 1976) | ≤10 por función |
| Complejidad cognitiva | Lo difícil que es seguir el código para una persona | Incrementos por cada ruptura del flujo lineal, peso extra por anidamiento (SonarSource, 2017) | ≤15 por función |
| Volumen de Halstead | Contenido de información del código | Longitud del programa × log2(vocabulario) a partir de operadores y operandos | Comparar tendencias, sin límite universal |
| Índice de mantenibilidad | Facilidad global de mantenimiento | Combina el volumen de Halstead, la complejidad ciclomática y las líneas de código | ≥20 en la escala 0–100 de Visual Studio |
| Acoplamiento entre objetos (CBO) | De cuántas otras clases depende una clase | Número de clases acopladas distintas (Chidamber & Kemerer, 1994) | Cuanto más bajo, mejor; revisar las clases por encima de 10–14 |
| Profundidad de herencia (DIT) | A qué profundidad está una clase en su jerarquía | Niveles desde la clase raíz | Revisar por encima de 5 |
| Churn del código y hotspots | Con qué frecuencia cambia el código complejo | Commits o líneas modificadas por archivo a lo largo del tiempo, superpuestos a la complejidad | Refactorizar primero el 1–5% de hotspots principales |
Complejidad ciclomática
La complejidad ciclomática cuenta el número de rutas linealmente independientes de una función y sigue siendo la métrica de complejidad de código más utilizada. Thomas McCabe la introdujo en 1976; en la práctica equivale al número de puntos de decisión (if, else if, case, bucles, operadores lógicos en las condiciones, bloques catch) más uno.
McCabe recomendaba un límite de 10 por módulo, y la NIST Special Publication 500-235 (1996) repite esa recomendación y admite hasta 15 para equipos experimentados con buenas pruebas. El valor también indica a los testers el número mínimo de casos de prueba para una cobertura completa de rutas. Su debilidad es que trata un switch plano con diez casos y diez condiciones profundamente anidadas como igual de complejos, aunque a las personas les resulta mucho más difícil leer lo segundo.
Complejidad cognitiva
La complejidad cognitiva mide lo difícil que es entender el código para una persona, lo que la convierte en mejor indicador del esfuerzo de mantenimiento que la complejidad ciclomática por sí sola. SonarSource publicó la métrica en 2017 precisamente para resolver el problema del anidamiento descrito arriba.
Las reglas son sencillas: cada ruptura del flujo lineal suma un punto, cada nivel de anidamiento añade peso extra, y las estructuras abreviadas fáciles de leer, como un switch plano o una cadena de operadores null-safe, suman poco o nada. SonarQube marca por defecto las funciones por encima de 15. Los equipos que siguen ambas métricas suelen comprobar que la complejidad cognitiva se ajusta mucho mejor a la intuición de los desarrolladores sobre qué es «código difícil».
Medidas de complejidad de Halstead
Las medidas de complejidad de Halstead estiman el contenido de información y el esfuerzo mental del código a partir del recuento de operadores y operandos. Maurice Halstead las definió en 1977 y la mayoría de las herramientas de análisis estático todavía las calculan.
- Vocabulario: el número de operadores distintos más el de operandos distintos.
- Longitud: el número total de operadores y operandos.
- Volumen: la longitud multiplicada por el logaritmo en base 2 del vocabulario, aproximadamente el tamaño del programa en bits.
- Dificultad y esfuerzo: valores derivados que estiman lo difícil que es escribir o entender el código.
Las métricas de Halstead son más útiles como líneas de tendencia y como entrada del índice de mantenibilidad. Por sí solos, sus valores absolutos son difíciles de interpretar entre lenguajes.
Índice de mantenibilidad
El índice de mantenibilidad combina el volumen de Halstead, la complejidad ciclomática y las líneas de código en una única puntuación sobre lo fácil que es mantener un módulo. La fórmula original de la década de 1990 producía valores de hasta 171; Microsoft Visual Studio la reescala a 0–100 y considera bueno un valor de 20 o más, moderado entre 10 y 19 y bajo por debajo de 10.
El índice resulta práctico para los paneles y para detectar los peores archivos de una gran base de código heredada. Como mezcla varias señales, oculta el motivo de una mala puntuación, así que analice siempre las métricas subyacentes antes de decidir qué refactorizar.
Acoplamiento, cohesión y profundidad de herencia
Las métricas de acoplamiento y herencia miden la complejidad estructural entre módulos en lugar de dentro de una sola función. Una clase que depende de otras veinte es arriesgada de cambiar aunque cada uno de sus métodos sea sencillo.
La referencia clásica es el conjunto de Chidamber y Kemerer de 1994: acoplamiento entre objetos (CBO), profundidad del árbol de herencia (DIT), falta de cohesión en los métodos (LCOM) y respuesta de una clase (RFC). Para servicios y módulos, la misma idea se aplica a nivel de arquitectura: fan-in, fan-out y ciclos de dependencias muestran dónde un cambio se propagará por todo el sistema.
Churn del código y análisis de hotspots
El análisis de hotspots combina la complejidad con la frecuencia de cambio del control de versiones, y es la forma más práctica de decidir dónde la complejidad cuesta dinero de verdad. El código complejo que nadie toca tiene poca prioridad; el código complejo que cambia en cada sprint es de donde salen los defectos y los retrasos.
Sitúe cada archivo en un gráfico según su complejidad y el número de commits de los últimos seis a doce meses. Los archivos de la esquina superior derecha son sus hotspots. Herramientas como CodeScene lo automatizan, pero un script sencillo sobre git log y un informe de complejidad ofrecen una primera visión útil en una tarde.
¿Cómo se mide la complejidad a nivel de tarea?
A nivel de tarea, los equipos miden la complejidad con estimación relativa como los story points, con medición funcional estandarizada como los puntos de función y con factores de complejidad explícitos como las dependencias, la incertidumbre y la novedad. Estas medidas recogen riesgos que todavía no existen en el código.
Story points
Los story points son una medida relativa y sin unidades que combina la complejidad, la incertidumbre y el esfuerzo de una tarea en comparación con otras tareas del mismo equipo. La mayoría de los equipos usa una escala de Fibonacci modificada (1, 2, 3, 5, 8, 13) para que los elementos más grandes reflejen visiblemente más incertidumbre.
Los story points funcionan bien para el sprint planning dentro de un equipo. No sirven como medida de productividad entre equipos, y una investigación publicada en 2026 halló que reflejan el esfuerzo real con más precisión en las funcionalidades planificadas que en la corrección de errores, donde la complejidad oculta es habitual. Cuando una tarea llega a 13 puntos o más, divídala antes de comprometerse con ella.
Puntos de función
Los puntos de función miden el tamaño funcional del software desde el punto de vista del usuario, con independencia del lenguaje de programación. El análisis de puntos de función de IFPUG, normalizado como ISO/IEC 20926, cuenta cinco tipos de componentes: entradas externas, salidas externas, consultas externas, archivos lógicos internos y archivos de interfaz externos.
Cada componente se clasifica como simple, medio o complejo y se pondera en consecuencia, con un ajuste opcional según características generales del sistema. Los puntos de función requieren más esfuerzo que los story points, pero son comparables entre equipos y proveedores, por eso aparecen en contratos del sector público y en benchmarks de externalización. COSMIC (ISO/IEC 19761) es una alternativa más reciente que se adapta mejor al software en tiempo real y embebido.
Lista de factores de complejidad de una tarea
Una lista de factores de complejidad hace explícitos los impulsores de la complejidad de una tarea, de modo que las estimaciones se discutan con datos y no por intuición. Puntúe cada factor de 1 (bajo) a 3 (alto) durante el refinamiento:
- Complejidad del código de la zona afectada: complejidad ciclomática o cognitiva y condición de hotspot de los archivos implicados.
- Número de componentes y servicios afectados: cada módulo, base de datos o API adicional suma esfuerzo de integración y de pruebas.
- Dependencias externas: API de terceros, otros equipos, aprobaciones o entregas de proveedores fuera de su control.
- Claridad de los requisitos: si los criterios de aceptación, los casos límite y los requisitos no funcionales están por escrito.
- Novedad técnica: un lenguaje, framework, servicio en la nube o algoritmo nuevo para el equipo.
- Riesgo de datos y migración: cambios de esquema, rellenos de datos y compatibilidad con versiones anteriores.
- Impacto en cumplimiento y seguridad: tratamiento de datos personales, de pago o de salud que exige una revisión adicional.
Un total superior a unos 14 de 21 indica que la tarea debe dividirse, explorarse con un spike o ir precedida de una breve fase de descubrimiento. Nuestra guía de estimación de proyectos de software muestra cómo convertir estas puntuaciones en estimaciones por rangos.
¿Cómo se realiza un análisis de complejidad de tareas en el desarrollo de software?
Para realizar un análisis de complejidad de tareas, mida el código que la tarea va a tocar, puntúe sus factores de complejidad, compare ambos con umbrales acordados y decida si estimar, dividir, refactorizar primero o hacer un spike. Los seis pasos siguientes llevan menos de una hora en un epic típico.
- Mapear el cambio. Enumere los archivos, servicios, almacenes de datos e integraciones que probablemente modificará la tarea.
- Obtener las métricas de código. Ejecute su herramienta de análisis estático sobre esas zonas y anote la complejidad ciclomática, la complejidad cognitiva, el índice de mantenibilidad y la cobertura de pruebas.
- Revisar los hotspots. Examine la frecuencia de cambio y los defectos recientes de esos mismos archivos; un archivo complejo y modificado a menudo es una señal de alarma.
- Puntuar los factores de la tarea. Use la lista de siete factores anterior con los desarrolladores que harán el trabajo, no solo con el lead.
- Comparar con los umbrales. Señale cualquier función que supere sus límites y cualquier tarea con alta incertidumbre o muchas dependencias.
- Decidir y registrar. Estime tal cual, divida la tarea, programe un paso de refactorización o haga un spike acotado en el tiempo, y anote el motivo para que las retrospectivas puedan comprobar si el análisis fue correcto.
Repita el análisis de los elementos grandes en cada sesión de refinamiento. En unos pocos sprints, el equipo reúne sus propios datos sobre la relación entre las puntuaciones de complejidad y el cycle time real, algo mucho más valioso que cualquier benchmark del sector.
¿Qué puntuaciones de complejidad son demasiado altas?
Una función con una complejidad ciclomática superior a 10, una complejidad cognitiva superior a 15 o un índice de mantenibilidad inferior a 20 en la escala de Visual Studio merece revisión, y los valores muy por encima suelen justificar una refactorización. Los umbrales son puntos de partida, no leyes: acuérdelos en equipo y ajústelos a su lenguaje y su dominio.
| Métrica | Riesgo bajo | Revisar | Refactorizar |
|---|---|---|---|
| Complejidad ciclomática por función | 1–10 | 11–20 | 21+ |
| Complejidad cognitiva por función | 0–15 | 16–25 | 26+ |
| Índice de mantenibilidad (0–100) | 20–100 | 10–19 | 0–9 |
| Longitud de la función | Menos de 50 líneas | 50–100 líneas | Más de 100 líneas |
| Profundidad de herencia | 0–3 | 4–5 | 6+ |
| Story points por tarea | 1–5 | 8 | 13+ (dividir) |
La herramienta Radon de Python usa una clasificación similar para la complejidad ciclomática: A para 1–5, B para 6–10, C para 11–20, D para 21–30, E para 31–40 y F por encima de 40. El código generado, los parsers y las máquinas de estados pueden superar legítimamente estos límites; exclúyalos de forma explícita en lugar de bajar el listón para todos.
¿Cómo predicen las métricas de complejidad los defectos, el esfuerzo y el coste?
Las métricas de complejidad predicen los defectos, el esfuerzo y el coste porque el código complejo tiene más rutas que probar, más formas de fallar y más contexto que asimilar antes de cada cambio. Décadas de estudios empíricos muestran que la densidad de defectos aumenta con la complejidad y la frecuencia de cambio, por eso los datos de hotspots son una guía tan fiable.
- Defectos: los archivos con alta complejidad y mucho churn concentran de forma constante una parte desproporcionada de los errores en producción.
- Esfuerzo: cada ruta independiente necesita diseño, implementación y una prueba, por lo que la complejidad ciclomática fija un mínimo para el esfuerzo de pruebas.
- Lead time: el código difícil de entender ralentiza la revisión de código, aumenta el retrabajo y alarga el cycle time.
- Coste del cambio: las funcionalidades construidas sobre módulos complejos tardan más en cada versión, lo que se traduce en un coste creciente por cambio entregado.
Use estas relaciones como indicadores adelantados junto con las métricas de entrega. Nuestra guía de KPI del desarrollo de software explica cómo combinar las tendencias de complejidad con el cycle time, la tasa de fallos de cambios y los defectos escapados.
¿Qué herramientas miden la complejidad del código?
La mayoría de los equipos mide la complejidad del código con una plataforma de análisis estático en la CI, una regla de linter específica del lenguaje y, en bases de código grandes, una herramienta de análisis de comportamiento que incorpora el historial del control de versiones. Empiece por lo que se integre en su pipeline actual.
| Herramienta | Lenguajes | Qué mide | Ideal para |
|---|---|---|---|
| SonarQube / SonarQube Cloud | Más de 30 lenguajes | Complejidad ciclomática y cognitiva, duplicación, code smells, quality gates | Equipos que quieren un único quality gate en la CI |
| CodeScene | La mayoría de los lenguajes habituales | Hotspots, salud del código, acoplamiento de cambios, riesgo de conocimiento en el equipo | Priorizar la refactorización en bases de código grandes |
| Lizard | C/C++, Java, C#, JavaScript, Python, Go y otros | Complejidad ciclomática, longitud de las funciones, número de parámetros | Comprobaciones ligeras desde la línea de comandos |
| Radon | Python | Complejidad ciclomática, métricas de Halstead, índice de mantenibilidad | Proyectos en Python y scripts de la CI |
| Regla complexity de ESLint | JavaScript, TypeScript | Complejidad ciclomática por función | Bloquear funciones complejas en el momento del commit |
| PMD | Java, Apex y otros | Complejidad ciclomática y cognitiva, NPath, acoplamiento | Bases de código en Java y Salesforce Apex |
| Métricas de código de Visual Studio | Lenguajes .NET | Índice de mantenibilidad, complejidad ciclomática, acoplamiento de clases, profundidad de herencia | Equipos de .NET |
Sea cual sea la herramienta, ejecútela en cada pull request y haga fallar la compilación solo con las infracciones nuevas. Bloquear toda la deuda heredada desde el primer día garantiza que el gate acabe desactivado.
¿Cómo cambian los asistentes de código con IA las métricas de complejidad en 2026?
Los asistentes de código con IA hacen que las métricas de complejidad sean más importantes, no menos, porque producen código más rápido de lo que los equipos pueden revisarlo y a menudo prefieren la duplicación a la reutilización. Las tendencias de complejidad y duplicación son hoy de las señales más claras para saber si el código generado por IA mejora o deteriora una base de código.
- Aumenta la duplicación: el análisis de GitClear de 2025 sobre 211 millones de líneas modificadas registró un fuerte aumento de los bloques de código duplicados durante 2024, a medida que se extendían los asistentes de IA.
- Aumenta la inestabilidad: el informe DORA de 2025 concluyó que la adopción de la IA sigue asociada a una mayor inestabilidad en la entrega de software.
- Cambia el dimensionamiento de las tareas: el código repetitivo se abarata, de modo que el esfuerzo restante se concentra en la integración, los casos límite y la revisión, algo que los factores de complejidad recogen mejor que las líneas de código.
Reglas prácticas para 2026: mantenga los gates de complejidad de las pull requests generadas por IA igual de estrictos que los de las escritas por personas, vigile la duplicación junto con la complejidad cognitiva y pida a los asistentes que refactoricen funciones complejas, no solo que escriban otras nuevas. Nuestro panorama de herramientas de IA para el desarrollo de software describe las salvaguardas que usamos.
¿Cómo se puede reducir la complejidad de las tareas y del código?
La forma más eficaz de reducir la complejidad es dividir las tareas grandes, refactorizar los hotspots en pasos pequeños y diseñar módulos con límites claros, para que cada cambio toque el menor código posible. Reducir la complejidad es mantenimiento continuo, no un proyecto de limpieza puntual.
- Dividir las tareas en vertical: entregue porciones finas de valor para el usuario en lugar de grandes capas horizontales, para que cada tarea se mantenga por debajo de 8 puntos.
- Extraer funciones y usar cláusulas de guarda: los retornos tempranos y las funciones pequeñas y bien nombradas eliminan el anidamiento y reducen rápidamente la complejidad cognitiva.
- Sustituir los condicionales por polimorfismo o tablas de consulta donde la lógica de ramificación no deja de crecer.
- Refactorizar primero los hotspots: dedique el presupuesto de refactorización a las zonas donde se solapan la complejidad y la frecuencia de cambio, un poco en cada sprint.
- Reducir el acoplamiento: introduzca interfaces claras entre módulos y elimine los ciclos de dependencias.
- Escribir pruebas antes de refactorizar: las pruebas de caracterización y el desarrollo guiado por pruebas hacen que la simplificación sea segura.
- Aclarar los requisitos pronto: unos criterios de aceptación poco claros son un impulsor de complejidad a nivel de tarea que ningún código limpio puede corregir.
Las prácticas de calidad se refuerzan entre sí: la revisión de código, las pruebas automatizadas y los quality gates en la CI descritos en nuestra guía de aseguramiento de la calidad en el desarrollo de software evitan que la complejidad vuelva a colarse.
Errores habituales con las métricas de complejidad
Los errores más habituales son convertir las puntuaciones de complejidad en objetivos individuales, confiar en una sola métrica, ignorar el contexto y medir sin actuar. Cada uno hace que las cifras sean menos fiables sin que el código sea más simple.
- Usar las métricas para clasificar a los desarrolladores: la gente manipulará las cifras, por ejemplo dividiendo funciones de forma mecánica sin mejorar el diseño.
- Mirar una sola cifra: una complejidad ciclomática baja con un acoplamiento alto sigue siendo código arriesgado.
- Ignorar el contexto: un parser o una máquina de estados puede necesitar una complejidad alta; exclúyalo de forma consciente.
- Bloquear por la deuda heredada: los gates que fallan con el código antiguo acaban desactivados; controle el código nuevo y mejore el antiguo de forma gradual.
- Tomar los story points como la verdad sobre la complejidad: los puntos son una ayuda de planificación propia de cada equipo, no una medida objetiva.
- Medir sin decidir: si los datos de complejidad nunca cambian una estimación, una división o un plan de refactorización, deje de recogerlos.
Preguntas frecuentes
¿Qué son las métricas de complejidad de tareas en el desarrollo de software?
Las métricas de complejidad de tareas en el desarrollo de software son medidas cuantitativas de lo difícil que es comprender, construir, probar y mantener una unidad de trabajo. Incluyen métricas de código como la complejidad ciclomática, la complejidad cognitiva, el volumen de Halstead, el índice de mantenibilidad y el acoplamiento, y medidas de tarea como los story points, los puntos de función y las puntuaciones de factores de dependencias, incertidumbre y novedad.
¿Cómo se hace un análisis de complejidad de tareas en el desarrollo de software?
Mapee los archivos y servicios que va a tocar una tarea, obtenga con análisis estático la complejidad y la cobertura de esas zonas, compruebe si son hotspots con cambios y defectos frecuentes, puntúe factores como las dependencias y la claridad de los requisitos, compárelo todo con umbrales acordados y después estime, divida, refactorice primero o haga un spike.
¿Cuál es una buena puntuación de complejidad ciclomática?
Una complejidad ciclomática de 10 o menos por función es el objetivo comúnmente aceptado, según la recomendación original de McCabe y las directrices del NIST. Los valores de 11 a 20 merecen revisión y pruebas adicionales, y las funciones por encima de 20 suelen ser candidatas a refactorización, salvo que se trate de código generado, parsers o máquinas de estados deliberadas.
¿Cuál es la diferencia entre la complejidad ciclomática y la cognitiva?
La complejidad ciclomática cuenta las rutas independientes de una función y sirve para planificar las pruebas. La complejidad cognitiva, introducida por SonarSource en 2017, mide lo difícil que es leer el código para una persona penalizando el anidamiento y las rupturas del flujo lineal. Un switch plano obtiene una complejidad ciclomática alta pero una complejidad cognitiva baja.
¿Los story points son una medida de la complejidad?
Los story points son una medida relativa que mezcla complejidad, incertidumbre y esfuerzo para un equipo concreto. Ayudan en el sprint planning, pero no son una métrica de complejidad objetiva y no deben compararse entre equipos. Para un tamaño funcional comparable, use los puntos de función; para el riesgo del código, las métricas de análisis estático.
¿Qué herramientas miden la complejidad del software?
Las herramientas populares en 2026 incluyen SonarQube para la complejidad ciclomática y cognitiva con quality gates en la CI, CodeScene para el análisis de hotspots y de salud del código, Lizard y Radon para comprobaciones ligeras desde la línea de comandos, la regla complexity de ESLint para JavaScript y TypeScript, PMD para Java y Apex, y las métricas de código de Visual Studio para .NET.
Publicado el 5 de noviembre de 2026. Fuentes: McCabe, A Complexity Measure (1976) (en inglés); NIST SP 500-235, Structured Testing (1996) (en inglés); SonarSource, Cognitive Complexity white paper (en inglés); Microsoft, Code metrics values (en inglés); IFPUG, Function Point Analysis (ISO/IEC 20926) (en inglés); GitClear, AI Copilot Code Quality 2025 (en inglés); DORA, State of AI-assisted Software Development 2025 (en inglés).