← dev-notes
REFACTORING · PARTE 3 DE 3

Gestión de
Deuda Técnica

Lo que separa a un programador de un Ingeniero de Software: reconocer, medir y pagar la deuda deliberadamente

REFACTORING · P3
📉 Cuadrante de Fowler 🧹 Boy Scout Rule 🛡 Red de seguridad ⚡ vs. Performance 📐 Refactoring to Patterns
01 El cuadrante de la deuda técnica — Martin Fowler
DELIBERADA
INADVERTIDA
IMPRUDENTE            PRUDENTE
⚠ PRUDENTE + DELIBERADA
Deuda aceptable a corto plazo
"Debemos salir ya al mercado; después refactorizaremos."
La decisión es consciente y documentada. El equipo conoce el coste. Es deuda legítima si existe un plan de pago real. El riesgo: el "después" raramente llega sin presión explícita.
→ Documentar y planificar el pago
🚨 IMPRUDENTE + DELIBERADA
La más peligrosa
"No tenemos tiempo para tests ni para diseño."
El equipo sabe que está haciendo mal y lo hace igual, sin plan de corrección. Genera deuda exponencial: el código futuro se construye sobre cimientos rotos.
→ No negociar: esto no es velocidad, es riesgo
✅ PRUDENTE + INADVERTIDA
La deuda inevitable del aprendizaje
"Ahora que terminamos, vemos una mejor forma de haberlo hecho."
El equipo es competente y reflexivo. Solo después de terminar aparece el mejor diseño. Es el resultado natural de la iteración. Aquí nace el refactoring como práctica continua.
→ Refactorizar en la próxima iteración
⚡ IMPRUDENTE + INADVERTIDA
La brecha de conocimiento
"¿Qué es un patrón de diseño? ¿SRP?"
El equipo no sabe que está generando deuda. No es malicia — es falta de conocimiento. El remedio no es solo refactorizar: es invertir en formación y mentoring.
→ Formación + code review + pair programming
💡
La metáfora financiera — Ward Cunningham
Cunningham acuñó el término "deuda técnica" en 1992. La analogía es precisa: puedes pedir prestado velocidad ahora tomando atajos, pero pagarás intereses en forma de tiempo extra para entender, modificar y testear ese código. Como toda deuda: a veces es racional, pero la tasa de interés crece con el tiempo.
02 Estrategia de refactoring progresivo — cómo pagar la deuda
🧹
PRINCIPIO · R. MARTIN
Boy Scout Rule
"Deja el código un poco mejor de como lo encontraste." No necesitas un sprint de refactoring. Cada vez que tocas un archivo, mejora algo pequeño: renombra una variable, extrae un método, elimina código muerto. El efecto acumulado es transformador.
🚫
ANTI-PATRÓN
Big Bang Refactoring
Intentar refactorizar todo el módulo de una vez. Es la causa número uno de refactorings fallidos. El código queda en un estado intermedio que no compila, los tests fallan en cascada y el equipo abandona. Siempre en pasos pequeños y verificables.
📅
ESTRATEGIA
Refactoring oportunista
Refactoriza antes de añadir una funcionalidad (preparar el terreno) o después de que funciona (limpiar lo que hiciste). Nunca en medio. El refactoring se paga con la siguiente tarea, no en un bloque aislado.
03 La red de seguridad — tests como prerequisito absoluto
AXIOMA DEL REFACTORING
No existe refactoring
sin tests en verde.
Si los tests no están en verde antes de empezar, lo que estás haciendo es cambiar código a ciegas — no refactorizar. La suite de tests es el contrato que garantiza que el comportamiento observable no cambió.
⚡ Si no tienes tests: escríbelos primero. Characterization Tests → capturan el comportamiento actual, incluso si es incorrecto.
✅ Antes de refactorizar
Todos los tests en verde. Suite completa que cubre el comportamiento del código que vas a mover.
🔄 Durante el refactoring
Ejecuta los tests después de cada paso. Si algo falla, revierte el último cambio — no sigas acumulando cambios rotos.
✅ Después del refactoring
Todos los tests siguen en verde. El comportamiento externo es idéntico — solo el diseño interno cambió.
04 Refactoring vs. Performance — un falso dilema
🐢
EL MITO
"El refactoring hace el código más lento"
A veces el refactoring crea más objetos intermedios o llamadas a métodos adicionales. Esto puede introducir una micro-latencia. Esta preocupación es, en casi todos los casos, prematura.
⚡
LA REALIDAD SENIOR
Legibilidad habilita la optimización real
Un código limpio y bien estructurado es más fácil de perfilar (profiling). Solo cuando mides y encuentras el cuello de botella real (con datos) optimizas ese punto específico — no antes. La optimización prematura es el origen de la mayoría de los bugs de rendimiento.
📏
Donald Knuth — la regla del 97%
"La optimización prematura es la raíz de todos los males. El 97% del tiempo, debemos olvidar las pequeñas eficiencias." Un senior no optimiza lo que no ha medido. El flujo correcto es: código claro → perfilar bajo carga real → identificar el cuello de botella → optimizar ese punto. En ese orden, nunca al revés.
05 Refactoring to Patterns — Joshua Kerievsky
CONCEPTO CLAVE · KERIEVSKY 2004
A veces el destino del refactoring no es solo código más limpio — es la emergencia natural de un patrón GoF completo.
Los patrones no se diseñan desde el principio: evolucionan a partir del código existente cuando la presión del cambio los hace necesarios. El catálogo de Fowler es el camino; los patrones GoF son algunos de los destinos.
🔀
TÉCNICA → PATRÓN
Replace Conditional → Strategy
El switch sobre tipos evoluciona hacia una jerarquía de implementaciones de una interfaz. El patrón Strategy emerge del refactoring, no de un diseño top-down.
🧅
TÉCNICA → PATRÓN
Wrap method → Decorator
Envolver un método para añadir comportamiento antes/después — logging, auditoría, métricas — puede evolucionar al patrón Decorator cuando hay múltiples aspectos ortogonales.
🏭
TÉCNICA → PATRÓN
Extract Class → Factory
Cuando la creación de objetos se complica (múltiples ramas condicionales para instanciar), Extract Class sobre la lógica de creación puede revelar el patrón Factory Method.
06 Checklist — cuándo refactorizar y cuándo no
✅ Refactoriza cuando...
🟢Vas a añadir una funcionalidad y el código actual la hace difícil de insertar.
🟢Durante una code review identificas un smell claro y tienes los tests que lo respaldan.
🟢Encuentras código duplicado al añadir la misma lógica por segunda vez.
🟢Los tests tardan mucho en ejecutarse porque el código está muy acoplado.
🟢Acabas de terminar y ves claramente un diseño mejor — iteración normal, deuda inadvertida prudente.
🟢Aplicas Boy Scout Rule: mejoras algo pequeño cada vez que tocas el archivo.
🚫 No refactorices cuando...
🔴Los tests no están en verde. Primero haz pasar los tests, luego refactoriza.
🔴Estás añadiendo funcionalidad simultáneamente. Viola la regla de oro de Fowler.
🔴El código está cerca de un deadline crítico sin plan de testing. El riesgo supera el beneficio.
🔴Planeas reescribir ese módulo completo en las próximas semanas. Refactorizar código condenado es desperdicio.
🔴Es un Big Bang Refactoring de todo el módulo sin pasos verificables intermedios.
🔴Solo porque "no te gusta estéticamente" sin smell claro ni problema de mantenibilidad demostrable.
07 Tips de entrevista senior — frases que marcan la diferencia
01
"Refactorizo cuando el código me dificulta añadir la siguiente funcionalidad — no por estética."
Demuestra pragmatismo. El refactoring al servicio del producto, no de la perfección abstracta. Los entrevistadores buscan esto en perfiles senior.
02
"Nunca refactorizo sin tener los tests en verde primero. Si no existen, los escribo como Characterization Tests."
Demuestra disciplina de ingeniería y conocimiento del concepto de Characterization Tests (capturar el comportamiento actual antes de tocarlo).
03
"Aplico la regla del Boy Scout: cada vez que toco un archivo, lo dejo un poco mejor. Refactoring continuo, no sprints de deuda."
Demuestra que entiendes la deuda técnica como algo que se gestiona continuamente, no con grandes intervenciones traumáticas.
04
"Cuando veo un switch sobre tipos que crece, no añado otro case — refactorizo a Strategy. El patrón emerge del código, no del diseño inicial."
Conecta Refactoring to Patterns (Kerievsky), OCP (SOLID) y Strategy (GoF) en una sola respuesta. Esto diferencia a un senior de un mid.
05
"La deuda técnica más peligrosa es la imprudente-deliberada. Sé identificarla y defenderme de ella con argumentos de coste, no de elegancia."
Demuestra que conoces el Cuadrante de Fowler y que puedes hablar de deuda técnica en términos de negocio — velocidad, riesgo, coste — no solo de código limpio.
🗺
Mapa de las 3 partes de Refactoring
Parte 1 — El ciclo y los Code Smells: La regla de oro, Red-Green-Refactor, y los disparadores (Mysterious Name, Duplicated Code, Long Function, Primitive Obsession).
Parte 2 — El Catálogo de Técnicas: 7 maniobras en 3 grupos: Componer (Extract, Inline, Replace Temp), Mover (Move Method, Extract Class), Simplificar condicionales (Decompose, Replace with Polymorphism).
Parte 3 — Deuda Técnica: El Cuadrante de Fowler, Boy Scout Rule, la red de seguridad, Refactoring vs Performance y Refactoring to Patterns (Kerievsky).
REFACTORING · PARTE 3 DE 3 · DEUDA TÉCNICA
5 TIPS · CUADRANTE FOWLER ← Parte 2: Técnicas ↩ dev-notes