viernes, 13 de mayo de 2016

KBDoctor Complexity Index.

Agregué al KBDoctor un reporte que mide la complejidad de los objetos GeneXus de una KB.

No es fácil definir que objeto es complejo y cual es simple, por lo que definí un KBDoctor Complexity Index, que mide algunas de las cosas que me interesa simplificar.

El mismo esta definido de la forma

KBDoctor Complexity Index =
+100 por tener algún parametro sin IN: OUT: INOUT
+(MaximoNivelAnidacion * MaximoNivelAnidacion)
+ NumeroCiclomatico * 10 // Cuenta IF, Do While, For, Do Case
+ MaximoBloqueCodigo * 2



El indice intenta, que todos los objetos tengan reglas parm con IN y OUT, tener un nivel de anidacion bajo, bloques de codigo chico y un numero ciclomatico tambien chico.
En nuestros sistemas, si un objeto tiene un índice mayor que 500 es considerado muy complejo y debe cambiarse.

Estuve evaluando otros criterios para medir la complejidad como 
  • Cantidad de Rules
  • Cantidad de tablas accedidas
  • Cantidad de atributos accedidos

pero preferí una primer versión del indice que fuera mas sencilla y fácil de usar. 

El reporte también saca una suma del total de la KB (puede ayudar a medir que tan compleja es la KB) y la complejidad promedio. 

El tener un indicador, ayuda a realizar trabajos de mejoras en el código existente. 

Si alguien mas está trabajando en el tema, me gustaría intercambiar experiencias para avanzar mas rápido. 



viernes, 6 de mayo de 2016

Software que hace software


En los últimos años, hemos visto el avance de varias herramientas para el desarrollo de software, donde se automatizan algunas de las tareas de la creación de sistemas y de software en particular. 

Si pensamos dentro de la comunidad GeneXus tenemos
  • GeneXus que escribe código C# o Java, desde especificaciones
  • Patterns que escriben código GeneXus
  • GXTest y GXUnit que prueban programas
  • SecurityScan que detecta problemas de seguridad en KB GeneXus
  • Herramientas de Build y Deploy para el armado y la instalación de aplicaciones
  • KBDoctor ayuda a borrar objetos que no se usan mas
  • LSIExtension ayudan desarrollar con GeneXus
  • CleanVariables borra variables no usadas en objetos
  • TotalValidator controla problemas de usabilidad de la aplicación generada
  • GeneXus Server hace parte de la tarea de consolidación  
  • Herramientas de integración contínua (CruiseControl), nos ayudan a tener una versión instalable en todo momento
  • Pruebas de performance/carga se hacen con Jmeter y herramientas parecidas
  • Compración de navegaciones para ver cambios de funcionamiento
  • Traducción de aplicaciones (Localizacion) con el editor de lenguajes
Seguramente me olvido de varios mas. Muchas de estas tareas eran realizadas en forma totalmente manual, hace unos pocos años atrás. Esto me hace reflexionar en varios niveles. 

El futuro de la programación pasa por herramientas de software que nos automaticen parte de las tareas. Es una tendencia clara y queda bastante por automatizar.  Trazabilidad de requerimientos, generación de documentación y revisión de código son ejemplos claros de tareas que hacemos hoy que podrían automatizarse. 

No se si llegaré a ver sistemas generados 100 % por robots, pero vamos por buen camino. 


miércoles, 4 de mayo de 2016

KBSaveReorganization - Nueva Versión

Subí al marketplace una nueva versión de la extensión KBSaveReorganization
Esta extensión permite almacenar un script de la reorg en al KB, como un objeto del tipo File.
Esta versión, tiene ademas la nuevas funcionalidades:


  • Se salvan los programas pare ejecutar la reorg GeneXus en .NET en un directorio
  • Se crean scripts CMD para ejecutar la reorg forzada, otro en forma batch y otro para contar la cantidad de registros de las tablas a reorganizar.
  • Es compatible con Evolution 3. 
  • Ademas de funcionar en el IDE, funciona cuando se reorganiza con MSBUILD task. 


Si alguien la baja y la prueba, me agradaría mucho conocer sus opiniones.

viernes, 29 de abril de 2016

Validando estructura de la base de datos.


Estaba buscando una forma fácil de poder ejecutar en producción una validación de la estructura de la base de datos, para asegurarme que las tablas existen y que tienen todos los atributos de la versión que voy a instalar.

Parece un problema menor o de fácil solución, pero en algunas instalaciones, las reorganización de las tablas no dependen de nosotros o hay mas personas que pueden cambiar la estructura de la base de datos, por lo que tener una forma de chequear que el programa se va a encontrar la base de datos esperada viene muy bien.

Le agregué una opción al KBDoctor que genera varios scripts SQL para hacer algunas validaciones.

La mas simple, recorre todas las tablas de la aplicación y todos los atributos de dicha tabla y genera un script del tipo:

select attClave1, attClave2, attSec1, attSec2, attSec3 from Tabla where 1=0

No se tienen en cuenta los atributos formulas no redundantes e inferidos. De esta forma, si dicho script corre sin errores, existen grandes posibilidades que los programas funcionen sin errores.

domingo, 17 de abril de 2016

Mejorando la calidad del código en una KB de versiones anteriores.

Por la forma en que desarrollamos GeneXus, basados en conocimiento y no en la tecnología de moda, es común que tengamos algunas KB que fueron desarrolladas años atras, que aun sigan funcionando sin problemas.

Esto es una ventaja enorme, pero también nos trae el problema de como hacer para que dicho codigo utilice las nuevas funcionalidades, para facilitar su mantenimiento. 

Pongo un ejemplo concreto:

Parametros con IN:, OUT: e INOUT: 
En versiones viejas de GeneXus, todos los parámetros eran de entrada/salida. En versiones mas recientes, se puede especificar si los parámetros son de entrada o de salida, por lo que se evitan problemas de modificar un parámetro sin querer y queda mas claro que es lo que hace el objeto al tener especificado cuales parámetros son de entrada y cuales de salida. 
Ademas el código generado, es mas compacto, se usa menos memoria, etc. 

Teniendo tantas ventajas, es deseable poder cambiar todo el código viejo y obligar que todos los objetos especifiquen como se utilizan sus parámetros. Esto es mas fácil decirlo que hacerlo. Lo deseable es que todos los objetos nuevos o modificados ya tengan esa funcionalidad, pero permitir los viejos que sigan funcionando como antes, hasta que necesiten alguna modificación. 

Para lograr esto, hice una pequeña extensión (se llama KBDoctorValidator), que lo que hace es controla al salvar el objeto algunas características deseables del mismo e impide salvar si no cumple con los controles mínimos establecidos. 



Tengo esperanzas que con esta extensión el código viejo vaya mejorando poco a poco, a medida que el mismo necesite modificarse. 

Además de controlar que todos los parámetros especifiquen si son de entrada salida, puse algunos controles adicionales, como el nivel máximo de anidamiento, un indice de complejidad (basado en el número ciclomático) y el largo máximo de bloque de código

Espero que con estas simples controles se pueda ir mejorando la calidad del código de objetos viejos a medida que van siendo modificados.

No la voy a liberar aun, pues quiero ver como se comporta en GeneXus Server, como funciona en los import / export de cosas viejas, etc. Es posible que tenga que poner algunas excepciones para que se permita salvar en algunos casos (por ejemplo, controlando la fecha de ultima modificacion, para permitir importar xpz viejos).

Mi idea es poder incorporar en la extensión otros indicadores de calidad de código y también algunas heuristicas para evitar problemas o retrabajos, como puede ser el dejar en default el Contextual Title o Column Title en atributos o la descripción de tablas o grupos de subtipos.

También esta en los planes dar la posibilidad de cambiar los limites para aceptar o no un determinado cambio, de forma de poder hacer la personalización a nivel de toda la KB, de modo que una KB acepte objetos con anidamiento 10 y otra solo con anidamiento 5.