Las 4 reglas de Kent Beck que van antes que cualquier patrón de diseño

Un patrón de diseño es una solución con nombre y forma reconocible a un problema que se repite en el software — el Factory para crear objetos sin exponer cómo se construyen, el Observer para notificar cambios sin acoplar componentes entre sí. En 1999, mientras desarrollaba Extreme Programming, Kent Beck escribió cuatro reglas para saber si un diseño es simple, antes de llegar a cualquiera de esos patrones. Las escribió en orden de prioridad — cada una vale más que la siguiente.

1. 1 Pasa los tests.
2. 2 No tiene duplicación.
3. 3 Revela la intención.
4. 4 Tiene el mínimo número de elementos.¹

Ningún patrón de diseño aparece en esa lista. Y no es un descuido.

El orden importa más de lo que parece

Pasar los tests importa más que no tener duplicación. No tener duplicación importa más que revelar la intención. Revelar la intención importa más que tener pocas clases.¹

Esto no es una lista de buenas prácticas para tener en cuenta. Es una jerarquía. Si tienes que elegir entre duplicar código y romper un test, no dudas: rompes la duplicación, no el test. Si tienes que elegir entre un nombre más claro y una clase menos, eliges el nombre claro.

La mayoría de las discusiones sobre "clean code" tratan estas cuatro reglas como si pesaran lo mismo. No pesan lo mismo. Y confundir eso es el motivo por el que tanta gente prioriza mal.

La pelea que nadie necesitaba

Durante años hubo una discusión real sobre el orden de las reglas 2 y 3. Corey Haines las enseñaba en un orden. J.B. Rainsberger las aprendió en el otro.²

Rainsberger terminó escribiendo un post completo tratando de resolver la disputa — y la conclusión fue que no importa. Eliminar duplicación y mejorar nombres forman un ciclo: sacas duplicación, aparecen estructuras nuevas, esas estructuras necesitan nombres, mejoras los nombres, eso revela más duplicación. Da igual por dónde entres al ciclo.²

Lo interesante no es quién tenía razón. Es que dos personas que dominaban el tema discutían el orden de dos reglas — y ninguna mencionaba un patrón de diseño en el medio.

Por qué esto va antes que los patrones

El problema es que la mayoría los aplica al revés: agarra el patrón primero y busca dónde meterlo, en lugar de dejar que el problema lo pida.

Ahí es donde entra la regla 4 — mínimo número de elementos. Beck fue explícito con esto: en su época había mucho consejo de diseño que consistía en agregar capas de flexibilidad "por si acaso" se necesitaban en el futuro. El resultado, casi siempre, era un sistema más difícil de cambiar, no más fácil.¹

Un Strategy metido donde alcanzaba con una función. Un Factory para una clase que nunca va a tener una segunda implementación. Eso no es diseño simple. Es complejidad con certificado.

Las cuatro reglas son un diagnóstico.
Los patrones son una respuesta.

Aplicas la respuesta antes del diagnóstico y el resultado es peor que el problema original.

Por qué esto importa más hoy, con tanta IA de por medio

Hoy el código se escribe más rápido que nunca. Los modelos generan funciones, clases y arquitecturas completas en segundos. Pero generar código rápido no es lo mismo que generar código bueno — y ahí es donde estas cuatro reglas se vuelven más relevantes, no menos.

Cuando una IA te sugiere un patrón de diseño, lo hace porque ese patrón es estadísticamente común en el contexto que le diste, no porque haya diagnosticado que tu problema realmente lo necesita. La IA no corre las cuatro reglas antes de proponer la solución. Salta directo al patrón.

Eso significa que la responsabilidad de diagnosticar antes de aceptar recae completamente en ti. Si no sabes reconocer cuándo el código pasa los tests, no duplica lógica, revela la intención y tiene el mínimo número de elementos necesario, no vas a poder distinguir entre un patrón bien aplicado y uno metido de más solo porque "se ve más profesional".

Esa capacidad de diagnóstico —no la de escribir código— es lo que separa a quien usa la IA como amplificador de criterio de quien la usa como sustituto de él.

Qué hacer con esto

El cierre

La próxima vez que estés por aceptar un patrón de diseño —sugerido por una IA o por ti mismo— detente un segundo. Pregúntate si el problema que estás resolviendo pasó primero por las cuatro reglas, o si estás resolviendo un problema que todavía no existe.

Fuentes

1. Beck Design Rules — Martin Fowler. Formulación autorizada de las cuatro reglas de diseño simple de Kent Beck, con el orden de prioridad explicado por el propio Beck. martinfowler.com ↩
2. Putting An Age-Old Battle To Rest — J.B. Rainsberger. Análisis sobre la disputa del orden entre "no duplicación" y "revela la intención", y por qué ambas reglas funcionan como un ciclo en vez de una secuencia fija. blog.thecodewhisperer.com ↩