Desarrollando desde la trinchera.

Estoy leyendo un libro corto sobre Spec-Driven Development , una forma de desarrollar software con Inteligencia Artificial que propone algo que, a primera vista, parece bastante moderno. En lugar de empezar escribiendo código, se comienza describiendo qué sistema queremos construir. Se definen los requerimientos, el modelo de entidades, los casos de uso, las reglas, las restricciones y los criterios que debe cumplir la aplicación. Esa especificación —la Spec — pasa a ser uno de los principales artefactos del proyecto. A partir de ella, los agentes de IA pueden generar código, pruebas, documentación y realizar verificaciones para comprobar que lo implementado cumple con lo especificado. Mientras leía esto tuve una sensación curiosa: esto me resulta muy conocido. Mi proyecto de grado, a finales de los 80 A finales de los años 80 hice mi proyecto de grado en la Facultad de Ingeniería de la Universidad de la República. En aquella época, antes de comenzar a programar, nos exigían preparar u...

En  2022 publiqué Entity Provider Pattern . La idea era sencilla de explicar, pero bastante más difícil de implementar: dada una entidad representada por una Transaction GeneXus, generar una capa uniforme para consultar y modificar sus datos. El objetivo era evitar que cada desarrollador resolviera una y otra vez las mismas operaciones: Obtener todos los registros o una lista paginada. Consultar por clave o por otras condiciones. Verificar si una entidad existe. Insertar, modificar y eliminar mediante el Business Component. Publicar esas operaciones mediante un objeto API. Mantener una interfaz similar tanto para el acceso local como para el remoto. El ejemplo del artículo utilizaba una Transaction Customer y proponía generar Data Providers, Data Selectors, Procedures, SDT y un objeto API con operaciones como GetAll , GetByKey , Exists , Insert , Update y Delete . La intención no era solamente ahorrar algunas líneas de código. Buscaba definir una forma consistente de acceder a la...