Idea principal

Un desarrollador que rechaza una acción crea un caso de error, y le pone nombre. CannotEditInvoicedOrder dice "no se puede modificar un pedido facturado": la regla entera cabe en el nombre, sin comentario ni documentación. Nadie escribió ese nombre para documentar nada — era la manera más corta de designar el rechazo en el momento de programarlo.

De ahí un yacimiento inesperado en las partes del código peor ordenadas, aquellas donde ninguna regla se enuncia en claro: la lista de los nombres de casos de error. Se lee sin saber programar, puesto que solo se trata de leer nombres.

Otros tres lugares producen reglas, por rendimiento decreciente: las verificaciones hechas al inicio de la operación, antes de que se modifique nada; las restricciones de la base de datos — lo que debe ser único, lo que no puede quedar vacío; los controles de entrada en las pantallas.

Por qué es importante

Abre la lectura de las reglas a quienes no leen código, y son ellos — soporte, preventa, product management — quienes necesitan las reglas. La barrera técnica cae justo en la parte del trabajo que se creía más técnica.

También da un orden de ataque cuando el tiempo escasea: empezar por los errores, terminar por las pantallas, en lugar de recorrer los ficheros.

Matices y límites

Un nombre de error mal elegido enuncia una regla falsa con el mismo aplomo que uno bueno: la fuente es densa pero no verificada, y cada regla que sale de ella queda por confirmar.

Y la ausencia de casos de error no dice nada: un rechazo puede expresarse de otro modo, o no existir en ninguna parte porque la regla no se aplica. Un objeto descrito sin ninguna regla señala una descripción superficial, nunca un negocio sin reglas.

Preguntas abiertas

• ¿Qué hacer con las reglas que no rechazan nada — las que desencadenan, calculan o completan —, ya que no dejan ningún nombre tras de sí?