Idea

Un sistema comprendido es un sistema que se sabría reconstruir

Info

Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.

Idea principal

Preguntar "¿funciona?" a una aplicación desarrollada con un asistente no informa sobre su dominio: pantallas que responden, una base de datos que existe y una API que funciona conviven perfectamente con centenares de decisiones técnicas que nadie sabe explicar. La pregunta que discrimina es otra: ¿sabríamos rehacer este sistema en otro sitio, en otra tecnología?

Responder que sí supone saber dónde están los contratos entre API, dónde viven las reglas de negocio, qué pruebas describen el comportamiento esperado en lugar de la implementación actual. Esos tres puntos de referencia no se obtienen a posteriori: se imponen durante la construcción —exigir los contratos, hacer producir los juegos de pruebas y luego la pirámide de pruebas antes de desarrollar, negarse a que el negocio quede disperso por los endpoints—, incluso sin llegar a un enfoque DDD completo que el proyecto no justifique.

La reconstrucción no tiene por qué emprenderse. Sirve de pregunta de control, y su respuesta mide lo que el equipo sabe decir del sistema más que lo que el sistema muestra.

Por qué es importante

Esto da un criterio de calidad oponible allí donde la velocidad de entrega ya no dice nada. Una demostración funcional sale bien sea cual sea el estado de la comprensión; "¿sabría reconstruirlo?" falla precisamente cuando esta falta.

También transforma la comprensión en exigencia de diseño en lugar de virtud individual: son líneas de separación identificables las que la hacen posible, y se deciden en el momento en que se construye.

Matices y límites

Nadie reconstruye para verificar que habría sabido hacerlo. El criterio sigue siendo, pues, una pregunta planteada en conciencia, expuesta a la complacencia de quien responde: un sistema puede parecer reconstruible a quien lo ha pilotado y no serlo para nadie más.

Y no dice nada del valor del sistema: se puede saber rehacer idéntica una aplicación que no sirve a nadie, o cuya arquitectura es mediocre.

Preguntas abiertas

  • ¿Qué prueba corta —que otra persona retome un módulo, reescribir un componente sin lo existente a la vista— daría a este criterio una verificación que no dependa de la autoevaluación?