The Mikado Method - Mejoras a código que no conozco demasiado.

Leí el libro Mikado Method hace un tiempo y es sobre metodología para poder hacer cambios a sistemas de los cuales no se conoce demasiado o son entreverados (casi todos los sistemas grandes que conozco).

El nombre viene del juego Mikado, en el que hay que sacar los palitos, sin mover ninguno de los que quedan en el juego.  Con este método, consiste en encontrar el cambio que puedo hacer, que me ayude a conseguir una meta preestablecida, sin afectar nada del resto del sistema.

Lo que plantea es algo bastante sencillo (y hasta intuitivo) para cambiar sistemas que están funcionando. Para que el método funcione, hay que tener una forma de volver a un estado conocido y bueno del sistema, donde todo compile y no tengamos errores.

El método. 

Lo primero que plantea es definir lo que se quiere cambiar, como una meta a alcanzar.

Luego, plantea hacer una solucion "naive" a para lograr dicha meta e intentar compilar (y ejecutar si todo sale bien) la aplicación.

Una vez que aparecen errores, en vez de corregirlos, lo que recomiendan es escribirlo como pre-requisitos de mi meta en una hoja de papel, en una forma de grafo.

El paso que es importante, es que una vez encontrado algún error, se vuelve al estado anterior, haciendo un revert de todos los cambios. llevando el sistema a un estado conocido y sin errores.

Luego, en vez de trabajar en solucionar la meta, se trabaja en solucionar los pre-requisitos recién encontrados.

Si logro hacer estos cambios sin introducir errores, puedo subir esos cambios a mi manejador de versiones, y si aparecen errores, debo repetir el proceso, escribiendo lo que causa el error en el grafo y volviendo atrás los cambios realizados.

Es un método que he probado con Genexus y Genexus Server, y realmente permite ir haciendo cambios en forma mucho mas ordenada. en KB que no conozco demasiado.

Un ejemplo en una KB GeneXus. 

Con un ejemplo de su uso, tal vez quede mas claro y se puedan ver las ventajas. Lo voy a aplicar en una aplicacion GeneXus generada desde KB grande de varios miles de objetos, y me propongo reducir el acoplamiento de un modulo con el resto del sistema. Como ejemplo, tomo el modulo de Monedas/Cotizaciones, que tiene a su cargo el mantenimiento de las monedas y las cotizaciones de las mismas a lo largo del tiempo.

La meta que escribo es:

Reducir acoplamiento del módulo monedas. 

Una vez definida la meta, hago el primer paso que es CONGELAR UNA VERSION en el estado que tiene antes de empezar, para poder volver a esta version tantas veces como sea necesario.

La solución mas sencilla que se me ocurre para lograrlo, es cambiar la visibilidad por defecto que tendrán los objetos de dicho módulo, por lo que cambio esa propiedad en el módulo y la paso a PRIVATE y luego hago un build de todos los objetos del modulo y quienes lo referencian (esto se puede hacer con el KBdoctor).

Este cambio lo que logra es cambiar todos los objetos que con visibilidad por defaul a PRIVATE, entre ellos las tablas MONEDAS y COTIZACIONES.

Viendo el resultado de las navegaciones, puedo ver que hay varios objetos que tienen error, pues intentan acceder a las tablas del modulo que ahora son privadas.

Empiezo a escribir los diferentes pre-requisitos en un papel, para mostrar como afecta cada cambio al siguiente paso.

Analizando los errores, puedo ver que hay 3 casos diferentes.

• Algunos programas que usan las tablas en forma directa, pudiendo usar las API del modulo. 
• Objetos que deberian estar en el modulo y están mal ubicados. 
• Objetos que usan las tablas para cargar Dynamic ComboBox de monedas. 

Anoto todo estos pre-requisitos en un papel dibujando el grafo de dependencias

Una vez llegado a este punto, VUELVO A UN ESTADO CONOCIDO. Esto lo hago, volviendo al estado de la versión congelada y haciendo otro build all

Este punto es un poco anti-intuitivo al principio, pues parece una perdida de tiempo, pero tiene la enorme ventaja que siempre deja una KB en estado usable, Puedo cortar el proceso de mejora en cualquier momento (por ejemplo para agregar una nueva funcionalidad) y retomarlo días más tarde, sin preocuparme demasiado por las dependencias.

Una vez que tengo los pre-requisitos claros y volví a un estado conocido, puedo ponerme a trabajar en resolverlos. Por ejemplo, puedo hacer un DataProvider en el módulo de MONEDAS y cambiar todos los Dynamic Combo para que lo usen en vez de acceder directamente a los atributos y las tablas.

Cuando termino un pre-requisito, debo evaluar si el mismo por si solo agrega valor y deja el sistema mejor que antes. Si las respuesta es si, puedo (y debo) subirlo a GeneXus Server, para que los demás ya vean dicha mejora y lo marco como resuelto en el grafo.

Sigo realizando los cambios, haciendo el arreglo y luego disparando los chequeos  que se consideren oportunos, en este caso pueden ser:

* Build all sin errores.
* Comparar navegaciones (no cambia ninguna navegación en los objetos no cambiados)
* Comparar WSDL de los Webservices del sistema y todo sigue igual
* Pruebas automáticas de GXTest sin errores.
* Pruebas manuales del módulo de Monedas

A medida que voy terminando los pre-requisitos, voy marcando en el grafo cuales son las tareas terminadas y subiendo los cambios a GXServer.

Cuando tengo todas los pre-requisitos marcados como realizados, la meta ya se logró,. puedo dar por terminado el trabajo.

Ventajas del método. 

La mayor ventaja que le encuentro a este método, es que permite hacer cambios grandes, en pequeños pasos, y siempre teniendo el sistema en un estado instalable. Es ideal para mejorar sistemas que tienen años funcionando y que pocos se animan a cambiar.

Ademas permite trabajar en el trunk, sin necesidad de crear versiones de trabajo en GXServer que son siempre costosas de mantener y sincronizar.

Referencias

https://pragprog.com/magazines/2010-06/the-mikado-method
https://www.manning.com/books/the-mikado-method