¿Es «código limpio» siempre vale la pena el tiempo, o a veces «lo suficientemente bueno» está bien?

Question

Accepted Answer

**Depende de la vida útil del código y su radio de impacto.** El código limpio da resultados excepcionales para código que vive y cambia; «lo suficientemente bueno» es la decisión correcta para código desechable, prototípico o raramente modificado. La habilidad está en ajustar tu inversión a la situación, evitando tanto la negligencia como la sobre-ingeniería.

## El principio: adaptar el esfuerzo a la vida del código

La calidad del código es una **inversión**, y como cualquier inversión su retorno depende del tiempo y la exposición. Las dos preguntas a hacer:

- **¿Cuánto tiempo vivirá este código?** El código leído y modificado durante años merece claridad; un script único no.
- **¿Cuál es su radio de impacto?** Un módulo central tocado por muchas personas y del que dependen rutas críticas merece cuidado; una esquina aislada que raramente cambia no.

## Cuándo el código limpio claramente gana

- Código que **cambia frecuentemente** — la claridad se recupera cada vez que alguien lo lee o lo edita.
- Código **compartido, central, o de larga vida** — el costo de la confusión se multiplica entre personas y tiempo.
- Cualquier cosa donde un **error es costoso** — pagos, autenticación, integridad de datos.

## Cuándo «lo suficientemente bueno» es la decisión correcta

- **Código desechable** — spikes, experimentos, migraciones únicas, un script que eliminarás mañana.
- **Prototipos** destinados a validar una idea, no a sobrevivir.
- **Código raramente tocado y bajo riesgo** donde el pulido compra poco.

## Los dos modos de fallo

| Fallo | Se parece a | Costo |
|---|---|---|
| **Negligencia** | enviar desorden a código que vivirá | cambios futuros lentos, bugs, erosión |
| **Sobre-ingeniería** | sobre-ingenierizar código que no importará | tiempo perdido, abstracción prematura |

Ambos son desperdicio real. «Lo suficientemente bueno» es una opción *deliberada, contextual* — no una excusa para ser descuidado, y no una licencia para pulir para siempre.

## Por qué es importante

Esta pregunta separa a los ingenieros que aplican calidad **dogmáticamente** de aquellos que la aplican **económicamente**. Tratar el código limpio como una religión desperdicia esfuerzo en desechables; tratarlo como opcional pudre los sistemas en los que confías. El criterio senior consiste en saber *qué tipo de código tienes en mano* e invertir en consecuencia — y poder explicar ese compromiso es exactamente el tipo de pensamiento pragmático que los equipos quieren ver.

Fallo	Se parece a	Costo
Negligencia	enviar desorden a código que vivirá	cambios futuros lentos, bugs, erosión
Sobre-ingeniería	sobre-ingenierizar código que no importará	tiempo perdido, abstracción prematura