Que está haciendo GeneXus con nuestra forma de resolver problemas?

Conversando con un amigo me dijo la siguiente frase:

"GeneXus necesitaría tener algo para forzar a pensar en el modelo de datos".

Él estaba comparando la forma de desarrollo tradicional (lenguaje de programación y DBMS SQL) contra GeneXus.

Con las herramientas mas tradicionales había que hacer una análisis inicial para llegar a un modelo de datos. Una técnica bastante usada, era el hacer diagramas de Entidad-Relación, en papel (y muchas veces con reglas con rombos y cuadraditos) y recién con este modelo de datos, se generaban los scripts para la generación de la tablas necesarias y en ese momento se empezaba a programar.

Estas etapas, eran indispensable para empezar a codificar por lo que se exigía un buen período de tiempo para pensar en el modelo de datos y se sabía que cualquier error que se encontrara después, daba gran trabajo en arreglarlo. Había que re-hacer el diagrama, ajustar los scripts de modificación de la base de datos y por ultimo cambiar los programas, lo cual era un trabajo respetable.

Generalmente los scripts se realizaban por personas especializadas (DBA) que conocían el modelo de datos y eran los que solucionaban en partes los conflictos que podían plantearse en una etapa muy temprana del desarrollo. Por ejemplo, si un desarrollador solicitaba que se creara una tabla de Empresas, pero en el modelo de datos, ya existía una tabla con dicha semántica, se producía una negociación/capacitación para que el modelo de datos existente fuera bien usado, sin producir tablas duplicadas.

Que es lo que sucede con GeneXus?.
Con GeneXus todo es mucho mas fácil, pues se pueden ingresar las visiones que los usuarios tendrán de los datos, y con esto se generarán automáticamente las diagramas de tablas (que pocas veces son mirados) y los scripts de generación de las mismas.
En forma casi inmediata se empieza a programar, (en realidad al ingresar la estructura de las transacciones ya se esta "programando") pues ya pueden generarse los programas para ingresar y modificar datos de dichas tablas.

Introducir un error en el modelo de datos, se ve como algo de costo mucho menor, peus si tengo que modificar algo, lo cambio y se generan en forma automática los programas que modifica la base de datos y copian los datos. Los cambios en los programas hay que hacerlos manualmente y revisar los programas que usan las tablas modificadas, pero esto es percibido como un trabajo chico.

Como cada desarrollador es autosuficiente, para realizar los cambios y no es necesario comentar con otro las modificaciones que estoy realizando.

En el ejemplo anterior donde un desarrollador con una visión parcial del sistema quiere hacer una tabla nueva de Empresas, la hace y es mas difícil detectar los objetos (y el trabajo) duplicado, pues nadie con una visión global del proyecto llega a chequearlo nunca, pues el DBA no es indispensable.

Comparando las metodologías
Con la forma de desarrollo tradicional, se tenían puntos de control, donde intervenían expertos. Estos eran mas o menos indispensables, y el proceso era mucho mas lento. Se trataba de detectar los problemas en forma temprana porque la corrección de un modelo de datos erróneo tenía un costo altísimo.

Con Genexus, se pierden puntos de control y el proceso es mucho mas rápido. Esto trae como consecuencia la sensación que es fácil/barato corregir estos errores, por lo que no importa mucho cometerlos, lo cual no es del todo cierto.

Se necesitan crear metodologías que acompañen el desarrollo para lograr compatilizar la velocidad que brinda la herramienta con un diseño razonable.

Algunas de las posibles "soluciones" que estuvimos conversando son :
  • Especificaciones de los cambios mas detalladas con un pre-analisis detallado (pueden llegar a ser prototipos generados con GeneXus, pero no "oficiales").
  • Chequeos obligatorios del modelo de datos por el "dueño del modelo".
  • Capacitación en modelado de datos de los desarrolladores del grupo.
  • Antes de crear algo nuevo, tener una instancia de revisar si no existe ya.


Por un lado, veo bastante injusto que se plantee que una herramienta dificulta el desarrollo correcto, pues hace todo mas fácil y rápido**. Pero por otro lado, GeneXus también debería colaborar un poco, pues en las ultimas versiones, no hay ni siquiera una forma fácil de intercambiar un listado de tablas entre los desarrolladores, pues el viejo y querido List Database de las versiones anteriores a Genexus no se tiene mas ni en la X ni la Evolution I.

La solución mas definitiva, seria en tener herramientas que me permitan visualizar el modelo de datos en forma mejor (no se bien cual, pero mejor que las actuales) y también dificultar que alguien cree cosas duplicadas. Me resultó un lindo tema para pensarlo un poco mas.

** Sería como decir que no puedo escribir buenos cuentos, pues con los computadoras y editores de texto puedo escribir y corregir mucho mas rápido que haciéndolo a mano o en una maquina de escribir mecánica.


Comentarios

  1. Muy bueno el post Enrique.

    ¿Cuanta gente de la comunidad colabora con extensions? ¿El List Database no se puede hacer fácil con una?

    ¿Cómo se llama la toolbar que pusiste abajo al pié del blog? muy buena.
    saludos

    ResponderBorrar
  2. Creo que con los CP 2.0, se van a hacer varias extensiones nuevas y mas gente va a participar.

    El List Database se puede hacer facil con una extension. Lo que veo como contra, es que Artech va a implementarlo pues es algo necesario entonces quedas con una extension que nadie va a utilizar. Me parece que es mas productivo hacer otras extensiones.


    La toolbar se llama wibiya widget. Se puede encontrar en http://www.wibiya.com/

    ResponderBorrar

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.