La pócima de la eterna juventud - Aplicaciones #Genexus


 En el ultimo evento GeneXus, hicieron hincapié en que GeneXus permite tener "Eternal youth for your code"

Por un lado, el codigo es cada vez mas importante, pero por otro lado, cada vez intentamos tener menos codigo y el mismo queda bastante escondido. Por eso creo que lo mejor es hablar de aplicaciones que se mantengan actualizadas en vez de juventud eterna. Pero mejor le dejo eso a los de marketing que saben de esas cosas.

De lo que si puedo opinar, pues hace muchos años que mantengo aplicaciones GeneXus es de como hacer para tener aplicaciones actualizadas a las ultimas tecnologias. 

Lo fundamental, es tener claro que una porción de la aplicación va a tener que ser cambiada para adaptarse a los cambios tecnológicos y tratar de minimizar dicha porcion de codigo, es lo que hace que sea mas o menos fácil el cambio de version. 

Interfaz de Usuario

En primer lugar, las cosas que sufren mas los cambios son aquellas que tiene interfaz de usuario. Si analizamos los cambios por los que me ha tocado pasar

  • Interfaz de caracteres (Pantalla verde / Lisados)
  • Win Forms (Transacciones / WorkPanels / Listados) 
  • Web Forms (Transacciones / Webpanels / Listados PDF)   
  • SD Forms (Transacciones / SDPanels)
Todos estos cambios fueron en unos 20 años, por lo que cada un poco mas de 5 años se agrega una nueva forma de interactuar con los usuarios y de a poco se va sustituyendo lo viejo por lo mas nuevo, pero durante un buen tiempo conviven. 

Dentro de poco, tendremos solo Panels y seran mas abstractos aun. 

Supongo que cuando incorporemos nuevas formas de interactuar con los usuarios, como voz, realidad aumentada, holografía o lo que se les ocurra, vamos a tener que cambiar nuevamente esta prate del sistema. O cuando se incorporen nuevos dispositivos. 

Por que digo todo esto? Porque sabiendo que la interfaz de usuario, es la que mas cambia, hay que tratar de aislrla lo mas posible del procesamiento del negocio. O sea, tratemos que los objetos que manejan interfaz de usuario, hagan todo lo necesario para mostrar, ingresar y validar los datos que usa el usuario, pero el procesamiento hay que hacerlo en objetos específicos. 

De esta forma, cuando venga la próxima exigencia de renovar nuestra aplicación, nos alcance con un cambio chico y no necesitemos una cirugía mayor. 

Como consejo básico, no programar nada de lógica de negocio en eventos de paneles (SDPanels, Transacciones, Webpanels, Panels) sino que conviene hacerlo en procedures, data providers, que son mucho mas tolerante a los cambios tecnológicos. 

Modelo de datos. 

Para lograr que una aplicación sea fácil de mantener actualizada, el mejor consejo es trabajar en tener el mejor modelo de datos posible. Dedicar tiempo a tener las tablas necesarias (y solo las necesarias) con buenos nombres y buenas descripciones ayuda muchísimo en el proceso. 

Tener integridad referencial definida en la base de datos, es muy bueno para tener mejor calidad de datos. Complica un poco la programación, y molesta cuando hay que hacer actualizaciones manuales en la base de datos, pero las ventajas son mucho mas que las desventajas. 

Algunas otras cosas deseables del modelo de datos

  • Atributos basados en dominios
  • Dominios con semántica
  • Atributos con nombre, descripcion, titulo, titulo contextual y titulo de columna bien puesto
  • Atributos bien formateados (pictures)
  • Borrar atributos que no están en ninguna tabla
El modelo de datos, es de las cosas que menos cambia y por lo tanto trabajar en tenerlo bien definido, siempre da buenos resultados. Además, los cambios técnicos y migración de datos, entre diferentes repositorios de datos siempre es mas fácil, si se tiene bien controlado el modelo de datos. 

Conozco aplicaciones GeneXus que pasaron de AS/400, DBF, SQLServer (varias versiones) hasta terminar en una base de datos en la nube. Todo esto en 30 años. 

Interfaces bien definidas. 

Otra cosa en lo que conviene trabajar en en definir claramente los mensajes, api o como le quieran llamar de los diferentes componentes de la aplicación.  Si la KB tiene módulos, conviene trabajar en que la conexión entre módulos sea lo mas chica posible, teniendo la menor cantidad de objetos públicos posibles. 
Si ya tienen objetos API, conviene definir los métodos que otros módulos pueden usar de mi modulo. 

Otros consejos
  • Borrar objetos que no se usan
  • Eliminar código repetido. 
  • El código externo (CSharp, Java, etc) concentrado en objetos específicos y no mezclado con otro código Genexus.
  • Cada objeto hace una sola cosa
  • Evitar navegaciones complicadas
  • Minimizar lo mas posible el uso de objetos externos
  • Borrar variables no usadas
  • Eliminar o minimizar Warnings
  • Sustituir comandos deprecated por código nuevo. 
Y por ultimo el consejo es migrar a versiones mas nuevas aunque sean migraciones de prueba y desechables, pues permiten la deteccion y correccion de errores por anticipado, lo cual hace mucho mas fácil el salto a la version definitiva. 

Comentarios

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

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

Aplicación monolítica o distribuida?

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