Todo código acumula deuda técnica: duplicación, coupling, abstracciones inadecuadas. El arte es saber cuándo y cómo pagarla sin perder velocidad.
Deuda técnica intencional vs accidental
Deuda intencional es cuando sabes que algo no es ideal pero está así porque fue decisión: "lanzamos rápido, perfeccionamos después". Es aceptable si está documentada y hay plan para pagarla.
Deuda accidental es cuando terminas con código feo sin haberlo planeado. Eso es problemático.
- Intencional: conocida, documentada, plazo claro de pago.
- Accidental: no planeada, sorpresa desagradable, frena futuro.
Cuándo refactorizar: indicadores
Si un módulo toma 5 días para entender, si cambios simples requieren editar 10 archivos, si el 50% del código es duplicación, es hora de refactorizar.
El criterio es: ¿refactorizar me pone más rápido en el futuro? Si sí, hazlo. Si no, espera.
- Duplicación significativa (>20%).
- Cambios frecuentes en el mismo sitio.
- Nuevo dev toma >3 días entender módulo.
Refactoring pequeño e incremental
No esperes a refactorizar todo de una vez. Refactoriza incrementalmente: un módulo, una función, una abstracción a la vez.
Eso permite mantener tests pasando, feature desarrollo en paralelo y rollback seguro si algo sale mal.
- Refactoriza mientras entiendes la lógica.
- Tests después de cada refactorización.
- Commits pequeños y frecuentes.
Testing: tu red de seguridad
No refactorices sin tests. Tests dan confianza de que el comportamiento no cambió. Sin tests, un refactorización es riesgo innecesario.
Si el código que vas a refactorizar no está testeado, escribe tests primero. Después refactoriza.
Refactorización sin tests es cirugía a ciegas. Puedes arreglarlo, pero también puedes romper cosas sin notarlo.
Comunicación: explica por qué refactorizas
No refactorices "porque el código era feo". Refactoriza "porque duplicación causa bugs", "porque cada cambio se dispersa", "porque es imposible testear".
Con razones claras, el equipo entiende que refactorización no es vanidad, es mantenimiento necesario.