Deuda técnica: cómo medirla y qué corregir primero
Para CTO y desarrolladoresDecisiones de CTO
Filip PapranecFundador de Digitaliko
La deuda técnica frena el desarrollo en cuanto cada nueva función tarda más que la anterior. Para la empresa significa un roadmap que se retrasa una y otra vez y desarrolladores que apagan fuegos en lugar de construir.
Se puede medir sin herramientas caras, con el historial de git y los errores. Corrija primero la deuda en el código que más cambia, no en el más feo.
La mayor parte de nuestro código la escribe la IA. Un sénior revisa cada cambio y responde de lo que corre en producción. Durante años hemos desarrollado un producto SaaS. La deuda de un producto que vive años no se resuelve en un sprint. Se reduce de forma continua.
¿Cómo saber si la deuda técnica le está frenando?
La deuda no se anuncia. Aparece como una lentitud que cada uno explica de forma distinta. Un botón que debería llevar un día lleva una semana. Marque lo que se cumple en su equipo. Cada punto sin marcar es una señal de deuda.
¿Cómo se mide la deuda técnica sin una herramienta cara?
No necesita una plataforma de análisis de código. Necesita responder a una pregunta: ¿dónde le cuestan más los cambios?
| Qué medir | Dónde encontrarlo | Qué le dice |
|---|---|---|
| Con qué frecuencia cambia un archivo | historial de git | dónde duele más la deuda |
| De dónde vienen los errores | tracker, hotfixes, incidencias | qué partes son frágiles |
| Tests en el código que cambia a menudo | informe de la CI | dónde cada cambio es un riesgo |
| Quién entiende un módulo | git blame, revisión | dónde depende de una sola persona |
| Tiempo desde el merge hasta el despliegue | logs de CI y despliegue | si le frena el código o el proceso |
| Estimación frente a realidad | sprints, tracker | cuánta deuda paga en cada tarea |
La señal más fuerte son las dos primeras filas juntas. Un archivo que cambia a menudo y además sigue generando errores es deuda con intereses. La lista de los archivos más modificados se obtiene con un solo comando:
git log --since="6 months ago" --format= --name-only | sort | uniq -c | sort -rn | head -20Junto a cada archivo del resultado, anote los errores que le afectaron. Las primeras filas son su lista.
¿Qué hay que corregir primero?
No lo más feo. Lo que más tiempo le cuesta ahora mismo. El orden que usamos:
01
Deuda en el camino del roadmap
Reducirla se nota en la siguiente función y puede defenderlo ante la dirección.
02
Código que cambia a menudo y tiene errores
Lo paga en cada tarea.
03
Tests y CI que pueden fallar
Sin ellos, cualquier reducción posterior es arriesgada.
04
Conocimiento en una sola cabeza
Si esa persona se va, la deuda se convierte en una caída del servicio.
La estética y pasarse a un framework más nuevo "porque es más nuevo" van al final. El código que nadie toca durante meses puede seguir siendo feo. No le cuesta nada. Si no se usa en absoluto, no lo reducimos, lo borramos. Hacemos lo mismo en nuestros propios repositorios: el código sin uso y las herramientas que nadie llama se eliminan.
Si la deuda en una parte es tan grande que se plantea reescribirla, empiece igual. Primero tests del comportamiento actual, después la decisión. Cómo los tests y la revisión frenan de verdad un cambio malo lo explicamos en Claude Code best practices para equipos: 7 reglas que funcionan.
¿Cómo se reduce la deuda sin parar el roadmap?
En el mismo flujo que las funciones. No en un "sprint de refactorización" que se aplaza una y otra vez porque llegó una función urgente.
- Una parte fija de la capacidad. Acuérdela de antemano con producto y no la toque en la primera urgencia.
- Reduzca donde trabaja. Cuando construya una función en un módulo con deuda, límpielo en el mismo pull request.
- Primero el test, después el cambio. Un test del comportamiento actual detecta lo que, si no, rompería.
- Ninguna deuda nueva sin registro. Si toma un atajo a propósito, anótelo como tarea con el motivo.
Así se ve en una función del roadmap:
Aquí la IA cambia las cuentas. Los tests para código existente, mover y renombrar eran caros, así que se aplazaban. Con IA son baratos. Pero sin reglas ni revisión, la IA añade deuda igual de rápido. Lo que le dejamos en el repositorio lo describimos en Reglas para el código de IA en un equipo.
Primeros pasos para este mes:
- Saque de git la lista de los archivos que más cambian.
- Junto a cada uno, anote los errores de los últimos meses.
- Elija tres puntos que bloquean la siguiente función del roadmap.
- Acuerde con producto una parte fija de la capacidad para la deuda.
- Compruebe que la CI puede frenar un merge malo.
Cuándo no lo recomendamos
- La deuda no le frena, simplemente no le gusta. Si ese código no cambia, déjelo. Dedique la capacidad al roadmap.
- El producto se va a cerrar o sustituir en unos meses. Reducir deuda en un código que se acaba no compensa.
¿Quiere reducir la deuda con alguien que lo hace a diario?
Un sénior se incorpora a su repositorio y a sus pull requests desde el primer día. Reduce la deuda que está en el camino del roadmap, junto a las funciones, no en su lugar. Así trabajamos como desarrollador externo para equipos de producto.
Escríbanos qué parte del sistema le frena más. Le respondemos en un plazo de dos días laborables con algunas preguntas sobre su trabajo. Después acordamos qué hacemos primero.
Si prefiere hablar antes, reserve una llamada introductoria de 15 minutos.
¿Qué archivo de su repositorio no se atreve a abrir nadie del equipo?
En resumen
- La deuda técnica se mide con el historial de git y los errores, sin herramientas caras.
- Corrija primero la deuda en el camino de la siguiente función del roadmap, no el código más feo.
- Antes del cambio: tests del comportamiento actual y una CI que pueda fallar.
- Redúzcala en pull requests normales, con una parte fija de la capacidad.
Preguntas frecuentes
¿Cómo se mide la deuda técnica?
Lo más sencillo es el historial de git junto con los errores. Los archivos que más cambian y además generan errores son la deuda que de verdad le cuesta tiempo. Además, observe cómo crecen las estimaciones de los cambios pequeños.
¿Qué hay que corregir primero?
La deuda en el código que necesita para la siguiente función del roadmap. Después, el código que cambia a menudo y tiene errores. El código que nadie toca, déjelo en paz, aunque sea feo.
¿Cómo se explica la deuda técnica a la dirección?
En tiempo y riesgo, no en calidad del código. Muestre cuánto más tardan los cambios en una parte concreta y cuántos errores salen de ella. Mejor aún, sobre una función del roadmap que la dirección está esperando.
¿La IA aumenta la deuda técnica?
Sin reglas ni revisión, sí, porque escribe rápido y sin contexto. Con reglas en el repositorio, tests y revisión por otra persona, ayuda a reducirla. Con IA, los tests y mover código salen baratos.
Pregunte a una IA sobre este artículo
La IA también tiene en cuenta nuestros otros artículos y la experiencia de proyectos reales.
ChatGPTClaudePerplexity
