Validación en runtime: decisiones tipadas en vez de booleanos, la propuesta de JEV

Un post de opinión ha puesto sobre la mesa un enfoque distinto para validar datos en producción: en vez de que cada comprobación se resuelva en true o false, cada resultado sería una decisión tipada y estructurada que se puede registrar y revisar después. El autor lo agrupa bajo el nombre JEV y lo ilustra con JavaScript. No hay repositorio, número de versión ni licencia a la vista.

El problema del sí o no

El argumento de partida es conocido para cualquiera que haya estado de guardia: una validación pasa en desarrollo y revienta a las tres de la mañana con un dato que nadie previó. El motivo no es que el código esté mal, sino que la capa de validación solo sabe contestar sí o no. Un booleano no dice qué campo falló, qué se esperaba en su lugar, ni si el fallo es duro o discutible. Tampoco deja nada con lo que reproducirlo a partir de una línea de log.

Como consecuencia, los equipos acaban añadiendo parches: objetos de error a medida, trazas improvisadas y código que trocea mensajes de excepción para adivinar qué pasó. Complejidad que no debería existir si la validación se hubiera diseñado para inspeccionarse, y no solo para dejar pasar o cortar.

El texto insiste en una distinción que se suele pasar por alto: que los tipos cuadren en compilación no garantiza nada sobre lo que llegará en ejecución. Una interfaz con un campo email de tipo string compila igual de bien con 'not-an-email' dentro que sin él, o con un campo que desaparece porque un servicio de arriba cambió su respuesta sin avisar.

Qué propone JEV

La idea central es que cada validación produzca un objeto tipado en lugar de un booleano: un outcome que distinga entre aceptado, rechazado y ambiguo, acompañado de los campos que explican el fallo. Con eso, lo que se registra no es el hecho de que algo falló, sino la decisión concreta que tomó el sistema. El mismo dato de entrada da siempre el mismo resultado estructurado, lo que hace la lógica comprobable igual que cualquier otra parte del código.

El autor acompaña el argumento con varios patrones que se pueden aplicar sin adoptar JEV. El primero, convertir el resultado en un tipo, aunque sea una unión discriminada mínima. El segundo, registrar también las validaciones que pasan, sobre todo las que quedan cerca del límite. El tercero, sacar las reglas de los manejadores de ruta y el middleware para poder probarlas aisladas. Y el cuarto, escribirlas pensando en la sesión de depuración que tocará meses después.

La parte aprovechable del texto es esa: son decisiones de arquitectura razonables y no dependen de ninguna herramienta concreta. Lo que no se puede comprobar es JEV. El post no enlaza código, ni documentación, ni una versión instalable, y termina remitiendo a un libro sobre el tema. Hasta que haya algo que descargar, leer el enfoque sirve; evaluarlo como herramienta, no.