Manejando la Deuda Técnica
Deuda técnica = Préstamo
La deuda técnica es como un préstamo: te permite avanzar más rápido hoy, pero pagarás intereses después. En un MVP, algo de deuda es estratégico. El problema es cuando te endeudas de más.
¿Qué es la deuda técnica?
La deuda técnica son todas las decisiones que tomas para ir más rápido hoy, sabiendo que tendrás que volver a arreglarlo después. Incluye:
Código sin refactorizar
Funciona, pero es difícil de mantener o extender
Bugs conocidos no críticos
Errores menores que no bloquean el uso principal
Casos edge no manejados
Situaciones poco comunes que causan errores
Falta de tests
Código que funciona pero sin validación automatizada
Tipos de deuda técnica
“Sabemos que esto no es ideal, pero necesitamos lanzar para validar. Lo arreglaremos después.”
✓ MVP strategy
“No tenemos tiempo para diseño. Hagámoslo rápido y ya.”
⚠ Peligrosa
“No sabíamos que había una mejor forma de hacerlo.”
→ Aprendizaje
“¿Qué es un patrón de diseño?”
✗ Falta de conocimiento
Matriz de deuda técnica de Martin Fowler
Deuda aceptable en un MVP
No toda deuda es mala. Aquí está lo que puedes dejar para después:
✓ Código duplicado (DRY más tarde)
Copiar-pegar funciona. Cuando el patrón sea claro, refactoriza.
✓ Hardcoded values
No necesitas un sistema de configuración complejo para el MVP.
✓ UI básica sin perfeccionar
Funcional > bonito. Puedes mejorar el diseño cuando tengas validación.
✓ Falta de tests automatizados
Tests manuales son suficientes para un MVP. Automatiza después.
✓ Procesos manuales
Hacer algo a mano hasta que tengas volumen para automatizar.
Deuda que NUNCA debes tomar
✗ Seguridad comprometida
NUNCA guardes contraseñas en texto plano, expongas API keys, o ignores validación de datos. No hay excusas.
✗ Pérdida de datos de usuario
Backups y manejo de errores en base de datos son obligatorios.
✗ Feature principal rota
Tu feature Must Have #1 tiene que funcionar perfectamente. Es el corazón de tu MVP.
✗ Código que no entiendes
Copy-paste de StackOverflow está bien, pero debes entender qué hace. Si no lo entiendes, eventualmente te explotará.
Documentando tu deuda
La clave es ser consciente de la deuda que tomas. Usa comentarios TODO:
// TODO: Refactorizar cuando tengamos más de 100 usuarios
// Esta implementación no escala bien
function processOrders(orders) {
// Iteración simple O(n²) - OK para <100 items
orders.forEach(order => {
...
})
}
// HACK: Workaround para bug en librería X
// Issue: https://github.com/lib/issues/123
// Remover cuando actualicemos a v2.0
Cuándo pagar la deuda
Criterios para priorizar refactoring
Cuando te bloquea implementar nuevas features
Cuando el mismo código te da problemas repetidamente
Cuando tienes presupuesto/tiempo dedicado a mejoras
Código que vas a reemplazar o eliminar pronto
Regla del 20%
Después del lanzamiento, dedica ~20% de tu tiempo a pagar deuda técnica. Si trabajas 40 horas/semana, 8 horas son para refactoring y mejoras. Esto evita que la deuda se acumule sin control.
Siguiente paso
En la próxima lección pondrás todo en práctica con un ejercicio guiado donde configurarás tu entorno de desarrollo y completarás tu primer sprint del MVP.