La importancia de llamarse KBDoctor.


En las diferentes versiones de Genexus, cada vez deducen mas cosas de la base de conocimiento y permiten generar mas codigo en forma "automática".
Esto trae como consecuencia, que cada vez es mas importante tener muy prolijo tanto el modelo de datos, como todas las propiedades de los atributos, tablas y demas objetos.

Solo para dar algunos ejemplos:

  • En versiones anteriores, los prompts generados por genexus, eran poco menos que inutilizables. Hoy en dia, se generan pantallas que son mucho mejores y personalizables, con lo que puedo considerar tenerlas en mi aplicación, sin que desentonen.
  • Antes cuando se generaba una grilla en los cabezales de la misma, se ponía la descripción del atributo como título de la columna. Como éste era algo largo, siempre había que cambiarlo.
  • No existían los patterns, por lo que todas las pantallas eran diseñadas y tocadas de forma que no importaba si un atributo o tabla quedaba con una descripcion con una falta de ortografía o un titulo mal ingresado porque de cualquier forma habia que hacer alguna adaptación.

Las ultimas versiones de GeneXus y en particular la Rocha, hacen posible que muchas mas cosas se puedan generar "mas automáticamente" y que los objetos generados sean lo suficientemente buenos como para no tener que modificarlos.

Entonces, pasa a tener una importancia mucho mayor el tener bien ingresados desde el principio las descripciones de los atributos, los títulos de los mismos, los nombres y descripciones de las tablas y de las transacciones.

Algunos de los problemas que intenta diagnosticar el KBdoctor (**) son justamente esos: Atributos que no tienen descripción, o tablas a las cuales las descripción les quedo default.

Cada vez es mas importante, hacer un esfuerzo grande en definir correctamente:
  • el modelo de datos (con los subtipos correctos)
  • nombre de los atributos
  • dominios del sistema
  • atributos con descripción, titulo de columna y titulo de fila
  • tipo de control por defecto de los atributos
  • nombres y descripción en transacciones
  • nombres y descripción en tablas
El tiempo dedicado a definir correctamente todos estas características, se verán luego recuperados con creces, cuando se genere código a partir de ellos, ya sea con Patterns, Drag and Drop de atributos en las pantallas, Copy / Paste. También es mas fácil de traducir una aplicación a la cual se ha usado mayormente los campos con la descripción default.

(**) Lo que diagnostica KBDoctor, aun es muy primitivo y necesita muchas mejoras. Debería poder mejorarse poniendole un poco mas de inteligencia a los reportes con heuristicas no demasiado complejas.

Comentarios

Entradas más populares de este blog

Aplicación monolítica o distribuida?

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.