El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia
HOME Mis cursos Finalizados
◄ Anterior
◄

Gestión de la Deuda Técnica

Siguiente ►
►

Todo sistema acumula, con el tiempo, decisiones de diseño que en su momento fueron rápidas o convenientes pero que dificultan el cambio futuro. A esa brecha entre el estado ideal del código y su estado real se le llama deuda técnica, una metáfora financiera acuñada por Ward Cunningham: igual que una deuda monetaria, genera "intereses" en forma de mayor esfuerzo en cada modificación. La deuda no es intrínsecamente mala —a veces es una decisión estratégica sensata— pero ignorarla lleva a la parálisis. En esta lección estudiaremos qué es exactamente, cómo clasificarla con el cuadrante de Fowler, cómo medirla y qué estrategias existen para pagarla, con la refactorización continua como práctica central.

Contenido

  1. Qué es la deuda técnica y la metáfora financiera
  2. El cuadrante de deuda técnica de Fowler
  3. Tipos y causas de deuda técnica
  4. Cómo medir la deuda técnica
  5. Estrategias de pago de la deuda
  6. Refactorización continua
  7. Errores comunes y consejos
  8. Ejercicios
  9. Conclusión

  1. Qué es la deuda técnica y la metáfora financiera

La deuda técnica es el coste implícito futuro de retrabajo causado por elegir una solución limitada o rápida ahora en lugar de un enfoque mejor que llevaría más tiempo.

La metáfora financiera tiene tres conceptos clave:

  • Principal: el esfuerzo necesario para corregir el problema (refactorizar, rediseñar).
  • Interés: el coste extra que pagas en cada cambio mientras la deuda exista (más lentitud, más bugs).
  • Apalancamiento: a veces endeudarse permite entregar valor antes y "devolver" después; puede ser una decisión racional.
graph LR
    A[Decisión rápida] --> B[Deuda técnica]
    B --> C[Interés: cada cambio cuesta más]
    C --> D{¿Se paga?}
    D -->|Sí| E[Principal saldado: código sano]
    D -->|No| F[Interés compuesto: parálisis]

Explicación del diagrama: una decisión rápida crea deuda; mientras no se salda el principal, se acumula interés en cada modificación. Si no se gestiona, el interés se compone hasta hacer el sistema casi inmodificable.

  1. El cuadrante de deuda técnica de Fowler

Martin Fowler propuso un cuadrante que clasifica la deuda según dos ejes: si se contrajo de forma deliberada o inadvertida, y si fue prudente o imprudente. Esto matiza el juicio moral sobre la deuda.

Imprudente Prudente
Deliberada "No tenemos tiempo para el diseño" "Entregamos ya y asumimos las consecuencias"
Inadvertida "¿Qué es una capa?" "Ahora sabemos cómo deberíamos haberlo hecho"

Interpretación de cada cuadrante:

  • Deliberada e imprudente: se sabe cómo hacerlo bien pero se decide no hacerlo por desidia. La más peligrosa.
  • Deliberada y prudente: decisión consciente y justificada (lanzar antes para validar mercado), con plan de pago. Aceptable.
  • Inadvertida e imprudente: falta de conocimiento o disciplina; el equipo ni siquiera sabe que está generando deuda. Se combate con formación.
  • Inadvertida y prudente: la deuda del aprendizaje natural; solo al terminar entiendes el dominio. Inevitable y sana.

La lección del cuadrante es que la deuda prudente y gestionada puede ser una herramienta estratégica; la imprudente es un problema de disciplina o conocimiento.

  1. Tipos y causas de deuda técnica

Tipo de deuda Ejemplo
De código Código duplicado, métodos enormes, nombres confusos
De diseño/arquitectura Acoplamiento alto, ausencia de capas, dependencias circulares
De pruebas Cobertura insuficiente, tests frágiles
De documentación Documentación obsoleta o inexistente
De infraestructura Versiones de librerías sin actualizar, entornos manuales
De dependencias Bibliotecas obsoletas con vulnerabilidades

Causas habituales:

  • Presión de plazos y entregas apresuradas.
  • Falta de conocimiento o experiencia del equipo.
  • Cambios de requisitos que invalidan decisiones previas.
  • Ausencia de tiempo dedicado a mantenimiento.
  • Rotación de personal y pérdida de contexto.

  1. Cómo medir la deuda técnica

La deuda es en parte intangible, pero existen indicadores cuantificables. Las herramientas de análisis estático (como SonarQube) calculan métricas y un ratio de deuda técnica.

Métricas habituales:

  • Code smells y issues de mantenibilidad detectados automáticamente.
  • Complejidad ciclomática: número de caminos independientes de un método; cuanto mayor, más difícil de probar y mantener.
  • Duplicación de código (porcentaje).
  • Cobertura de pruebas.
  • Technical Debt Ratio (TDR): coste estimado de remediación dividido por el coste de desarrollo.
# Ejemplo de configuración de quality gate en SonarQube
sonar.qualitygate:
  conditions:
    - metric: new_coverage          # cobertura del código nuevo
      op: LESS_THAN
      error: 80                      # falla si <80%
    - metric: new_duplicated_lines_density
      op: GREATER_THAN
      error: 3                       # falla si >3% de líneas duplicadas
    - metric: new_technical_debt     # deuda introducida por este cambio
      op: GREATER_THAN
      error: 60                      # falla si añade más de 60 min de deuda

Explicación: este quality gate impide que código nuevo degrade la salud del proyecto. En lugar de exigir limpiar toda la deuda histórica de golpe (inviable), aplica el enfoque "Clean as You Code": el código nuevo debe cumplir el estándar, conteniendo la deuda en su origen.

Indicadores indirectos valiosos:

  • Velocidad del equipo decreciente sin causa aparente.
  • Tasa de defectos creciente.
  • Lead time (tiempo desde commit hasta producción) en aumento.

  1. Estrategias de pago de la deuda

No toda la deuda debe pagarse, ni de la misma forma. Estrategias principales:

Estrategia En qué consiste Cuándo usarla
Pago incremental Mejorar un poco con cada cambio (Boy Scout Rule) Por defecto, siempre
Refactorización dedicada Reservar capacidad del sprint a saldar deuda Deuda localizada y conocida
Reescritura parcial Reescribir un módulo concreto Módulo crítico inmanejable
Reescritura total Rehacer el sistema Último recurso, muy arriesgado
Tolerar la deuda No hacer nada conscientemente Código estable que no se toca

Priorización: paga primero la deuda que está en zonas de alto cambio y alto impacto. La deuda en código que nunca se modifica genera poco interés; no merece la pena saldarla. Una matriz útil cruza "frecuencia de cambio" con "dolor que causa".

Recomendaciones de gestión:

  • Hacer la deuda visible (backlog, etiquetas, registro de deuda técnica).
  • Asignar una capacidad fija (p. ej. 15-20% de cada iteración) al mantenimiento.
  • Acompañar cada pago de pruebas que protejan el comportamiento.

  1. Refactorización continua

La refactorización es mejorar la estructura interna del código sin cambiar su comportamiento externo. Continua significa hacerla en pequeños pasos constantes, no en grandes proyectos esporádicos.

Regla de oro: refactorizar siempre bajo la red de seguridad de las pruebas. Sin tests, no es refactorización, es riesgo.

// ANTES: método largo, con varias responsabilidades y difícil de seguir
public double procesarPedido(Pedido p) {
    double total = 0;
    for (Linea l : p.getLineas()) {
        total += l.getPrecio() * l.getCantidad();
    }
    if (p.getCliente().esVip()) {
        total = total * 0.9;
    }
    if (total > 100) {
        total = total; // envío gratis
    } else {
        total = total + 5;
    }
    return total;
}
// DESPUÉS: extracción de métodos con nombres expresivos
public double procesarPedido(Pedido p) {
    double subtotal = calcularSubtotal(p);
    double conDescuento = aplicarDescuentoVip(p, subtotal);
    return aplicarEnvio(conDescuento);
}

private double calcularSubtotal(Pedido p) {
    return p.getLineas().stream()
            .mapToDouble(l -> l.getPrecio() * l.getCantidad())
            .sum();
}

private double aplicarDescuentoVip(Pedido p, double subtotal) {
    return p.getCliente().esVip() ? subtotal * 0.9 : subtotal;
}

private double aplicarEnvio(double total) {
    return total > 100 ? total : total + 5;
}

Explicación de la refactorización: aplicamos Extract Method para separar cada responsabilidad (subtotal, descuento, envío) en un método con nombre claro. El comportamiento externo no cambia —por eso es seguro si hay tests—, pero el método principal ahora se lee como una descripción del proceso. Esto reduce la deuda de código y la complejidad ciclomática.

Refactorizaciones frecuentes: extraer método, renombrar, extraer clase, reemplazar condicionales por polimorfismo, introducir parámetro objeto. Modernos IDE las automatizan de forma segura.

Errores Comunes y Consejos

  • Refactorizar sin pruebas. Es la causa más común de introducir bugs al "mejorar" el código. Primero la red de seguridad.
  • Mezclar refactorización con cambios funcionales en el mismo commit. Sepáralos: si algo falla, no sabrás si fue la mejora o la nueva función.
  • Esperar al "gran refactor" o la reescritura total. Casi siempre fracasa o nunca llega. La deuda se gestiona de forma continua e incremental.
  • Tratar toda la deuda por igual. Prioriza por impacto y frecuencia de cambio; ignorar esto malgasta esfuerzo en código muerto.
  • No hacer visible la deuda. Lo que no se mide ni se registra, no se gestiona. Usa el backlog y métricas.
  • Confundir refactorizar con reescribir. Refactorizar preserva el comportamiento en pasos pequeños; reescribir parte de cero y es mucho más arriesgado.
  • Consejo: adopta "Clean as You Code" para no degradar lo nuevo y la Boy Scout Rule para mejorar lo que tocas.

Ejercicios

Ejercicio 1. Clasifica en el cuadrante de Fowler las siguientes situaciones: a) "Lanzamos el MVP con persistencia en ficheros para validar el negocio y migraremos a BD si funciona." b) "Copié y pegué el módulo porque no sabía que existían las interfaces."

Ejercicio 2. Tienes deuda técnica en dos módulos: uno que se modifica casi cada semana y otro que no se toca desde hace dos años. Con recursos limitados, ¿cuál priorizas y por qué?

Ejercicio 3. Refactoriza este método extrayendo responsabilidades (suponiendo que existen pruebas):

public String generarSaludo(Usuario u) {
    String s = "";
    if (u.getEdad() < 18) s = "Hola joven "; else s = "Estimado/a ";
    s = s + u.getNombre();
    if (u.isPremium()) s = s + " (cliente premium)";
    return s;
}

Soluciones

Solución 1. a) Deliberada y prudente: decisión consciente y justificada, con plan de pago (migrar si el negocio funciona). Es una deuda estratégica aceptable. b) Inadvertida e imprudente: se genera por desconocimiento del diseño. Se combate con formación y revisión de código.

Solución 2. Priorizas el módulo que se modifica cada semana. La deuda genera "interés" en cada cambio; en un módulo de alto cambio ese interés se paga constantemente, así que saldarlo tiene un retorno alto. El módulo congelado hace dos años genera poco o ningún interés: tolerar su deuda es lo correcto mientras no haya que tocarlo.

Solución 3. Extraemos cada decisión a un método con nombre expresivo:

public String generarSaludo(Usuario u) {
    return tratamiento(u) + u.getNombre() + distintivoPremium(u);
}

private String tratamiento(Usuario u) {
    return u.getEdad() < 18 ? "Hola joven " : "Estimado/a ";
}

private String distintivoPremium(Usuario u) {
    return u.isPremium() ? " (cliente premium)" : "";
}

El comportamiento se preserva, pero el método principal expresa la intención y cada regla queda aislada y testeable.

Conclusión

La deuda técnica es inevitable, pero gestionarla es una decisión. Hemos visto que la metáfora financiera (principal e interés) explica por qué la deuda ignorada se vuelve paralizante, y que el cuadrante de Fowler nos ayuda a distinguir la deuda estratégica de la negligente. Aprendimos a medirla con métricas y quality gates bajo el enfoque "Clean as You Code", a priorizar su pago según impacto y frecuencia de cambio, y a saldarla mediante refactorización continua bajo la protección de las pruebas. Con esta lección cerramos el Módulo 2 de principios y tácticas de diseño: dispones ahora de un marco completo —desde el acoplamiento y la cohesión hasta la gestión de la deuda— para tomar decisiones de diseño conscientes. El siguiente módulo dará el salto a los estilos y patrones arquitectónicos que estructuran sistemas completos.

◄ Anterior
◄
Siguiente ►
►

Curso de Arquitectura de Aplicaciones

Módulo 1: Fundamentos de la Arquitectura de Aplicaciones

Módulo 2: Principios y Tácticas de Diseño

Módulo 3: Estilos y Patrones Arquitectónicos

Módulo 4: Arquitecturas Distribuidas y Microservicios

Módulo 5: Arquitecturas Dirigidas por Eventos y Mensajería

Módulo 6: Diseño Dirigido por el Dominio (DDD)

Módulo 7: Datos y Persistencia

Módulo 8: Arquitectura en la Nube y Despliegue

Módulo 9: Calidad, Seguridad y Observabilidad

Módulo 10: Evolución, Gobernanza y Casos Prácticos

El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia
© Copyright 2026. Todos los derechos reservados