Gestión de la deuda técnica.

Supongamos que tengo un sistema ya desarrollado y encuentro que los desarrolladores que lo hicieron (siempre son otros que ya no están !!!) hace años.

Por ejemplo, podemos decir que detectamos una oportunidad de mejora en una KB GeneXus desarrollada hace años, en una versión anterior de GeneXus, pues tiene algunos objetos que no especifican si los parámetros son IN, OUT o INOUT. Al no especificar nada, los parámetros quedan de entrada salida.

En las versiones anteriores de GeneXus todos los parámetros eran de entrada salida, pues no se podía especificar si el parámetro era solo IN o OUT.

Identificado el problema, es bueno ponerse un objetivo para corregirlo

Definir Objetivo

Todos los parámetros de los objetos de la KB deben especificar si son IN, OUT o InOut. 

Metodologías 

Una vez definido el objetivo, hay que definir cómo voy a realizar el cambio para lograr dicho objetivo.

Generalmente evaluo un par de formas de conseguir los objetivos:

Cambio Big bang. 

Es realizar el cambio en todos los objetos de la KB en una sola sesión.
De ser posible, se hace el arreglo y se corrige en forma definitiva.

Depende muchísimo de la cantidad y la complejidad de los objetos que hay que cambiar. En el caso de los parámetros IN/OUT es un cambio delicado, definí que era un cambio delicado para hacerlo todo en un solo lote.

Cambio paulatino. 

Si el cambio va a ser paulatino, implica que se hace un cambio de algunos objetos, se prueban y se ponen en producción.
Esto permite ir viendo avances, concentrando el riesgo en pocos objetos.

Para el manejo de de dicho cambio paulatino, conviene definir un indicador que mida el objetivo. En este caso, podría definirse un indicador que muestre cuantos objetos quedan en la KB con parámetros sin IN/OUT y medirlos en forma periódica.  Mi recomendación, es tener una página de documentación dentro de la KB registrando el avance del objetivo. De esta forma todos los integrantes del grupo de trabajo puede ver el avance del objetivo.

Seria algo muy simple, como esto:

Fecha Obj sin IN/OUT % del total
2018-11-20             873 91%
2018-12-06 456 95%
2019-02-04 150 98%
2019-02-13 73 99%
2019-05-30 0 100%
Si el cambio lo amerita, podemos hacer un programa que cuente la cantidad de objetos que aún faltan corregir.

Esta forma de trabajo nos ha resultado adecuada para bajar la deuda técnica de una KB.

Resumiendo.
  • Identificar problema/oportunidad de mejora. 
  • Valorar si vale la pena hacer el cambio. 
  • Definir objetivo a alcanzar y cómo medirlo
  • Definir metodología de trabajo.
  • Mientras objetivo no cumplido
    •    Arreglar los objetos mas críticos, probar e instalar.
    •    Documentar estado objetivo. 
  • Festejar el objetivo cumplido con todo el grupo. 






Comentarios

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.