La Cerca de Chesterton en el Refactoring Senior

El síndrome de "borrar código viejo porque me parece feo" es el instinto suicida número uno del dev Junior. Un Senior sabe que si un bloque de código bizarro está en producción desde hace 3 años, probablemente está atajando un edge-case que ni te imaginás.

La Tentación del "Clean Code Hacker"

Es tu primera semana en el proyecto. Entrás a un monolito heredado, das scroll por un archivo de TypeScript cuasi infinito y te topás con esta aberración de la naturaleza:

payment-gateway.ts

function processPayment(customer: Customer, amount: number) {
  // TODO: Refactor ASAP. Nobody knows why this is here.
  if (customer.legacyId === 999) {
    amount = amount - 0.01;
  }

  // ... resto de la lógica genérica
}

Tu primer instinto como dev "evangelizador de Clean Code" es borrarlo. Total, es código muerto, asimétrico y huele mal, ¿verdad? Lo borrás. Los tests (inexistentes en legacy) pasan. Hacés deploy un viernes a las 17:00.

Dos días después, producción se enciende fuego: resulta que acabás de borrar la compensación manual (hardcodeada) de un error de redondeo en la única pasarela de pago que procesa las cuentas de un segmento corporativo súper específico. Felicidades, tiraste la cerca y el ganado se escapó.

Archaeological Debugging: El Approach Senior

La programación profesional rara vez se trata de escribir; el 80% del trabajo de un Senior es leer y deducir. Un desarrollador Senior no adivina el propósito de un código mutante, hace arqueología digital.

Antes de tocar una sola línea de ese bloque maldito, tu flujo de trabajo tiene que involucrar git log y git blame para rastrear los orígenes del Pull Request. Usar la CLI de Git es la mejor forma de interactuar con los "fantasmas" del proyecto:

Terminal

# Busca en todo el historial del repo quién, cuándo y por qué se introdujo ese bloque exacto
git log -S "legacyId === 999" --patch

# O examina específicamente esas líneas en el archivo actual
git blame -L 40,50 src/payment-gateway.ts

La Única Red de Seguridad

Una vez que entendés por qué se colocó la cerca original y resolvés el misterio investigando en viejos PRs (o interrogando al equipo), recién ahí te ganás el derecho a derribarla o refactorizarla.

Pro-Tip: La única herramienta que te permite probar demoliciones de La Cerca de Chesterton con total paz mental es una suite sólida de automatización. Tomate el tiempo de configurar tests; son la cerca electrificada que deberás colocar antes de derribar el muro de barro defectuoso.

El buen código se escribe leyendo. El buen refactoring se hace investigando primero.

🔗 Sugerencias de lectura

La Navaja de Ockham en CSS: El contrapunto ideal. Cuándo simplificar agresivamente y cuándo no.
Efecto Zeigarnik en el Workflow: Por qué sentimos la urgencia irracional de "limpiar" todo antes de terminar el día.

…g CO₂