Cuándo dejar la deuda y cuándo pagarla

01 La única pregunta que importa

Antes de tocar nada: ¿qué cambia en este código el mes que viene? Si la respuesta honesta es "nada", la deuda puede esperar. Si la respuesta es "todo", el refactor probablemente ya se quedó corto.

La deuda técnica solo es deuda si cobra intereses. El código feo que nadie toca es solo código feo.

Esto suena obvio escrito. En la práctica casi todos los refactors empiezan al revés: alguien abre un archivo, le da grima, y a partir de ahí se justifica la inversión. El criterio profesional es invertir esos dos pasos.

02 Cuándo sí pagar la deuda

Pagas deuda cuando se cumple al menos una de estas tres condiciones — no porque "ya tocaba":

• El módulo está a punto de cambiar por una razón de producto.
• Te impide moverte: cada cambio en ese código rompe tres cosas distintas.
• Bloquea a alguien más: el "joiner" del equipo no puede entender qué hace.

03 Cuándo NO pagar la deuda

Los tres casos que veo repetirse y casi siempre salen mal:

• Cuando llega alguien nuevo al equipo y "quiere dejar su huella".
• Cuando un LLM te dice que el código está mal estructurado. Los LLMs tienen opiniones; no tienen contexto.
• Cuando lo que cambias hoy lo vas a tocar en seis semanas porque cambia el producto.

04 La forma del refactor importa

Si decides refactorizar: refactor + feature en el mismo PR es casi siempre un error. Una cosa cambia comportamiento; la otra preserva comportamiento. Mezclarlas convierte la review en arqueología.

# Lo que sí funciona:
# 1) PR de refactor → tests siguen verdes, cero cambio de API.
# 2) PR de feature → encima del refactor ya mergeado.

git checkout -b refactor/extract-pricing
// solo mover y renombrar; ningún test cambia

git checkout -b feat/new-discount-rule
// ahora el código tiene forma de aceptarlo

05 Resumen en una frase

Refactor con criterio = decir "no" a la mayoría, "sí" cuando hay razón, y partirlo del feature siempre.