¿Qué es el principio WET?

WET (Write Everything Twice, "Escribe Todo Dos Veces") es un acrónimo humorístico que nombra el antipatrón opuesto a DRY: el código en el que la misma lógica se repite una y otra vez en lugar de extraerse a un único lugar reutilizable. La sigla tiene varias lecturas irónicas que circulan entre desarrolladores: "Write Everything Twice", "We Enjoy Typing" (Disfrutamos Escribiendo) o "Waste Everyone's Time" (Haz Perder el Tiempo a Todos). Todas apuntan a lo mismo: cuando copias y pegas en vez de abstraer, el resultado es código mojado, duplicado y costoso de mantener.

Un ejemplo cotidiano: si pegas la misma validación de un formulario en cinco pantallas distintas en lugar de moverla a una función compartida, estás escribiendo código WET. Cada copia es una bomba de relojería: el día que cambie la regla de validación tendrás que acordarte de tocar las cinco.

El problema del código WET no es estético, es económico. La duplicación multiplica el coste de cada cambio futuro y es una de las formas más comunes de acumular deuda técnica.

Cuando una misma regla de negocio vive en varios sitios:

• El mantenimiento se dispara. Un cambio que debería ser de una línea se convierte en una cacería por todo el código para localizar cada copia.
• Aparecen inconsistencias. Si actualizas tres de cinco copias y olvidas dos, el sistema empieza a comportarse de forma distinta según la pantalla. Estos bugs son difíciles de detectar porque "el código está ahí" pero desactualizado.
• El onboarding es más lento. Quien llega nuevo no sabe cuál de las copias es la fuente de verdad ni cuántas existen.

El síntoma clásico es el "copy-paste programming": bloques casi idénticos separados por pequeñas variaciones. Señales habituales:

• Funciones que se diferencian solo en un par de literales o nombres de variable.
• La misma constante (una URL, un límite, un mensaje de error) escrita a mano en muchos ficheros.
• Lógica de cálculo o de formato replicada entre el frontend y el backend.
• Bloques if/else o switch repetidos con la misma estructura en módulos distintos.

La cura no es magia: se llama refactorizar. Extraes la lógica común a una función, una clase o un módulo y reemplazas cada copia por una llamada a esa única fuente. Es justo lo que persigue el principio DRY.

Imagina un cálculo de precio con IVA repetido en tres servicios:

// Pantalla de carrito const total = precio + precio * 0.21; // Pantalla de checkout const total = precio + precio * 0.21; // Email de confirmación const total = precio + precio * 0.21;

El día que el tipo de IVA cambie, o que un cliente esté exento, hay que tocar tres sitios y rezar para no olvidar ninguno. La versión seca (DRY) centraliza la regla:

function conIVA(precio, tipo = 0.21) { return precio + precio * tipo; }

Ahora la regla vive en un solo lugar, se testea una vez y cualquier cambio se propaga solo.

WET es una caricatura útil, pero aplicarla al revés también tiene trampas:

• Confundir "código parecido" con "código duplicado". Dos fragmentos que hoy se parecen pero responden a reglas de negocio distintas no son WET: forzar una abstracción común los acopla y te obligará a separarlos más tarde. La regla práctica suele ser esperar a la tercera repetición antes de abstraer.
• Sobreabstraer por miedo a repetir. El extremo opuesto de WET es un código tan abstracto y genérico que nadie entiende. Aquí ayudan principios como KISS y SOLID: mantén la solución simple y con responsabilidades claras. A veces un poco de duplicación honesta es preferible a una abstracción equivocada.
• Tratar WET como una recomendación seria. El nombre es sarcástico; nadie defiende escribirlo todo dos veces a propósito. Es una etiqueta para señalar un problema, no una guía a seguir.

La duplicación también encarece las pruebas: cada copia añade rutas de código que cubrir, así que el mismo comportamiento se acaba testeando varias veces o, peor, ninguna. Al centralizar la lógica, un único conjunto de tests unitarios protege todos los usos a la vez, algo coherente con prácticas como TDD. Menos código WET significa menos superficie de error y suites de prueba más sencillas de mantener.

• DRY (Don't Repeat Yourself): el principio que WET ridiculiza por contraste.
• Refactorizar: la técnica para secar código mojado sin cambiar su comportamiento.
• Deuda técnica: lo que se acumula cuando la duplicación se deja crecer.
• KISS y SOLID: guías para elegir la abstracción adecuada sin caer ni en WET ni en la sobreingeniería.