KBDoctor : Ejemplo de limpieza de una KB en producción.

Me pasaron una KB que esta en producción en GeneXus X Evolution 2, mantenida por dos desarrolladores, para hacerle una limpieza con el KBDoctor.

Por lo que vi, es una KB bien mantenida y bien desarrollada, sin demasiado cosas históricas o basura.

Me pareció un buen ejemplo para medir los resultados de una limpieza de la KB, eliminando todo lo que no se usaba.

El objetivo es llegar a una KB que tenga los mismos ejecutables que tenia la original, y funcionalmente equivalente a la anterior, pero sin ningún objeto, tabla o atributo que no sea util para la aplicacion.

Para esto, usé el KBDoctor para lograrlo. Partía de una KB sin errores de especificación, ni de generación por lo que el trabajo estaba bien avanzado.

Los pasos que realice fueron:

1) Hacer un backup de la KB.

Cree una versión congelada de la KB antes de la limpieza, para poder volver a recuperar algun objeto en caso de necesidad.  También hice un export de todos los objetos de la KB, de forma de tener una alternativa en caso que la KB se corrompa por algún motivo.

2) Borrar todas las variables no usadas en la KB.

Ejecute la opción que recorre todos los objetos y borra aquellas variables no referenciadas en el código o en el layout.

3) Borrar todos los objetos no referenciados.

Al borrar todos los objetos no referenciados varias veces, se logra eliminar todos aquellos objetos que no son main y que nadie esta invocando.  Esta KB no tenia calls dinámicos, por lo que fue facil ejecutar esta opción.

4) Marcar con GenerateObject = False a todos los objetos no alcanzables.

Como es una KB que tenia aplicado el pattern WorkWith, habia muchos objetos que si bien no eran alcanzables, estaban siendo referenciados, pues se referenciaban en forma circular.
Estos objetos no se pueden borrar en el paso anterior, porque alguien los llama, pero nunca nadie los va a ejecutar.

5) Reporte de aquellas tablas que no se usan.

Con el reporte que se invoca de la forma

se obtiene un reporte de que los objetos que realizan las diferentes operaciones (update/insert/delete/read) en las tablas.
Aquellas tablas que solo son leidas, hay que analizarlas para ver si se pueden eliminar del sistema.

Una vez que se tiene la tabla candidata, se puede ejcuar la opcion "Table - Transaction Relation" y ver que Transacciones son las que colaboran en la generacion de dicha tabla y eliminarlas (si fuera posible).

Esto puede traer algunos inconvenientes de normalizacion que hay que solucionar en forma manual.

6) Borrar subtipos no usados

 En el paso anterior, al haberse eliminado tablas, es necesario hacer un analisis de subtipos y borrar todos aquellos que ya no son necesarios.  Para este paso, es indispensable conocer el modelo de datos al cual se quiere llegar.

7) Eliminar atributos que no están en ninguna tabla.

La opcion Attributes/Remove Atributes without table permite borrar todos aquellos atributos que no estan en ninguna tabla y elimina tambien las referencias en variables que dicho atributo pueda tener.
Si esta referenciado en subtipos o en dataview sin tabla asociada no los borra los atributos.

8) Analizar cuales son los objetos no alcanzables.

En el paso 4) se genero una categoria KBDoctor.Unreachable, que contiene todos los objetos que no son alcanzables.
Hay que analizar cada uno de estos objetos y ver si son necesarios o pueden ser eliminados.

9) Reporte de atributos que solo estan en trasacciones.

Analizar el reporte de todos los objetos que solo estan en trasacciones, ayuda a detectar algunos atributos que alguna vez fueron utiles y ya no son utilizados en la KB. Borrarlos ayuda a no cometer errores.

Si la transaccion es no alcanzable, se puede sacar el atributo de la estructura  sin problemas.
Si la transaccion es alcanzable, hay que analizar si tiene sentido seguir teniendo dicho atributo, pues puede ser un atributo util, para consultas (por ejemplo, teléfono de un cliente, aunque es raro que nadie los use para nada mas).

10) Volver las transacciones a sus partes default. 

A todas aquellas transacciones que no pueden borrarse (porque definen tablas que se utilizan) pero no son referenciadas por nadie, volver todas sus partes al estado default. Esto significa que los formularios win y web, seran los por defecto y no tendran reglas ni eventos.
Luego de hacer este paso, volver a correr el que borra los objetos no referenciados.

NOTA IMPORTANTE:

Luego de cada uno de estos pasos hay que hacer un build all y corregir todos los errores que aparezcan.

KBDoctor no tiene en cuenta ningún proceso externo a la KB que esta analizando, por lo que si hay otros programas que usan la misma base de datos o los programas desde fuera de la KB, los mismos pueden verse afectados. Por ejemplo, hay que tener en cuenta stored procedures de la base de datos, scripts que puedan ejecutarse en la misma, triggers, etc.
También pueden haber Data Views de otras aplicaciones que usen los atributos que en esta KB ya dejaron de usarse.


Los números, antes y después de la limpieza son:

Números antes y después de limpieza con KBdoctor

Para que tomarse todo este trabajo?  Que ventajas tengo? 

Una de las principales ventajas, es que teniendo en la KB solo los objetos necesarios, el mantenimiento de la misma es mas facil y rápido. Solo hay que corregir aquellos objetos que se usan y no objetos inútiles. 

Otra beneficio es que teniendo una KB "limpita", es mucho mas fácil detectar cuando se introducen objetos de prueba o con problemas. Por ejemplo, si logramos eliminar todos los warnings de mi aplicación, apenas alguien introduce un objeto que tiene algun warning, el mismo puede ser corregido. 

En KB con objetos viejos y que no se usan, es muy común que los programadores no se preocupen que tengan warnings, pues "ya no se usa mas". Esto poco a poco rebaja la calidad de los controles que se hacen en la KB. 

Otra ventaja que puede medirse, es que los tiempos de especificación/generación son un poco mas rápido. 

En el KB del ejemplo, que es una KB chica de 1500 objetos, los tiempos de REBUILD ALL, fueron. 

El rebuild se hizo  casi 5 minutos mas rápido. Podríamos pensar que los build all también se verán afectados en un porcentaje similar (aunque es mas difícil de probar), por lo que podríamos asumir que los ciclos de especificación/generación serian algo asi como un 20% mas rápido, lo cual es una mejora muy buena desde mi punto de vista. 

El proceso de limpieza lo hice en un dia de trabajo y otro medio dia adicional para tomar los tiempos, contar los objetos, escribir este post, etc.  Las ventajas de la limpieza son bastantes para el trabajo que da hacerla y los resultados se prolongan en el tiempo. 

** “Ningún animal fue lastimado durante la realización de este post” **