El "Efecto Restauración" en el Código Legado

Quien ha restaurado un mueble antiguo sabe que el trabajo no es “pintar encima” hasta que quede brillante: primero hay que evaluar capas, entender la madera y decidir si conviene lijar hasta recuperar la veta o si la pieza ya no tiene estructura y merece un proceso más profundo. El código legado se comporta igual: años de parches, “hotfixes” del viernes y nombres que ya no reflejan el dominio pueden ocultar reglas de negocio valiosas — o convertirse en una trampa si el equipo confunde movimiento con progreso.

En este artículo uso la analogía del efecto restauración para explicar cómo abordar sistemas antiguos sin romanticizar el rewrite ni caer en el refactor infinito. La idea central es recuperar la veta original: la intención del negocio que el código alguna vez expresó claramente, antes de que la complejidad accidental la enterrara.

Qué significa “lijar” en una base de código real

Lijar es reducir asperezas sin cambiar el comportamiento observable: mejorar nombres, eliminar duplicación obvia, acotar efectos colaterales y cubrir con tests lo que hoy solo vive en la cabeza de una persona. Es trabajo que rara vez enamora en un demo, pero baja el riesgo de regresiones y prepara el terreno para decisiones mayores. En equipos distribuidos o en contextos de alta rotación —muy comunes en startups y consultoras en Costa Rica y LATAM— lijar es una forma de transferir conocimiento silencioso al repositorio.

Un error frecuente es confundir lijar con “tocar sin tests”. Si el módulo es crítico, la caracterización (tests que documentan el comportamiento actual, aunque sea imperfecto) es la lija de grano fino: no juzga si el negocio está bien, solo congela la realidad para poder evolucionar con seguridad.

Cuándo el barniz nuevo es inevitable

A veces la madera está podrida: acoplamientos imposibles, tecnologías sin soporte, o reglas de negocio contradictorias que nadie puede explicar sin contradicciones. Ahí, seguir lijando es carísimo. Un barniz nuevo equivale a una refactorización profunda o módulo nuevo detrás de una fachada, con migración gradual y métricas claras (latencia, errores, tiempo de despliegue).

• Señal 1: el costo de oportunidad supera el valor: cada feature pequeña tarda semanas por miedo a romper efectos colaterales invisibles.
• Señal 2: el dominio cambió radicalmente y el modelo mental del código ya no coincide con cómo vende o opera la empresa hoy.
• Señal 3: incidentes recurrentes por la misma zona, pese a parches incrementales.

Ejemplo: de “blob” a función con intención

El siguiente fragmento es deliberadamente simple: ilustra cómo recuperar intención sin cambiar resultados. En producción, acompañarías esto con tests y quizá extracción a archivos separados.

// Antes: “lija” necesaria — nombres opacos, mezcla de niveles
public decimal Calc(decimal a, decimal b, int t, bool x) {
  if (t == 1) return a * 0.5m;
  if (t == 2) return (a + b) * 0.0833m;
  if (x) return a - (a * 0.1m);
  return a;
}

// Después: misma lógica, veta más visible (ajusta nombres a tu dominio real)
public decimal CalcularProvisionMensual(
  decimal salarioBase,
  decimal variableOpcional,
  TipoCalculo tipo,
  bool aplicarRetencionEspecial
) {
  if (tipo == TipoCalculo.AguinaldoProporcional) return salarioBase * 0.5m;
  if (tipo == TipoCalculo.HorasExtraPromedio) return (salarioBase + variableOpcional) * 0.0833m;
  if (aplicarRetencionEspecial) return salarioBase - (salarioBase * 0.1m);
  return salarioBase;
}

Comunicación con negocio: el barniz también es política

Ninguna metáfora de carpintería reemplaza la conversación honesta con producto y operaciones. Si propones una reescritura, lleva costos, riesgos y alternativas. Si propones solo lijar, explica cómo eso desbloquea entregas en el próximo trimestre. El código legado casi siempre es un activo político: quien lo entiende tiene responsabilidad; quien lo critica sin contexto genera fricción. La restauración buena es técnica y empática.

Para SEO y para equipos: documentar decisiones (ADR breves), enlazar issues y mantener un glosario de términos del dominio ayuda a que la “veta” no dependa de una sola persona — algo esencial en mercados pequeños donde el talento rota entre fintechs, nearshore y producto propio.

Herramientas que hacen medible la restauración

Sin métricas, todo debate sobre legado se vuelve opiniones. Antes de tocar módulos sensibles, establece una línea base: tiempos de respuesta, tasa de errores, cobertura de tests donde exista, complejidad ciclomática aproximada o deuda acumulada en SonarQube/Semgrep. No persigas la métrica perfecta: persigue tendencias que puedas mostrar en una retrospectiva. Si después de lijar el código la incidencia baja y el tiempo de despliegue no empeora, tienes evidencia para pedir más presupuesto de mantenimiento.

En organizaciones con compliance (finanzas, salud, sector público), enlaza cada cambio a un ticket auditado y conserva diffs legibles. La “restauración” también es trazabilidad: quién autorizó, qué se probó, qué se asumió como riesgo residual. Eso no solo satisface auditores: forma parte del SEO interno del sistema — la capacidad de explicar el producto a futuros ingenieros sin depender del fundador.

Finalmente, celebra los micro-hitos: renombrar un agregado confuso, eliminar un flag muerto, documentar un caso borde. La cultura que reconoce pequeños avances sobre código feo pero honesto es la cultura donde la gente se anima a mejorar sin pedir permiso para una reescritura total cada vez que lee un archivo incómodo.