Una reingeniería no siempre significa la reescritura de nuestra aplicación Legacy en un lenguaje generalmente más reciente, pero, sin embargo, es la opción que hemos elegidos.

Cuando se trata ‘simplemente’ de reorganizar el código para que sea más fácil de mantener, pero sin portarlo en una nueva plataforma de software o de hardware – migración de Mainframe-Cobol a una arquitectura Unix por ejemplo – yo prefiero hablar de refactorización.

Os recuerdo que este blog no tiene pretensiones académicas, así que no voy a preocuparme de definiciones meticulosamente exactas, que conducen con mayor frecuencia en discusiones quadripelotectomias (1) entre especialistas que no tienen nada más que hacer que glosar sobre cada palabra.

Pero esto no impide un poco de precisión con el fin de evitar prejuicios y malentendidos. En primer lugar, hemos analizado qué acciones de refactorización podríamos considerar para nuestra aplicación Legacy C (Word 1.1a) utilizando el plugin SQALE. Hemos intentado una estimación del coste de estas acciones y un cálculo de ROI.

Hoy voy a hablar de algunos elementos a tomar en cuenta para una reingeniería.

Objetivos

La estrategia a nivel de la aplicación o del producto software es, obviamente, en el corazón de un plan de reingeniería: una plataforma de software y/o de hardware al final de su vida o demasiado costosa, la escasez de habilidades de TI para mantener la aplicación en esta plataforma, costes de mantenimiento muy altos, etc. Pero en cualquier caso, se desea mantener la aplicación, o el software en el caso de un proveedor de software, y no abandonarlo para sustituirlo con el desarrollo de una nueva aplicación.

Entonces, el paso preliminar en una reingeniería es una clara identificación de cuales son los objetivos.

Pero contrariamente a lo que se pudiera pensar, una reingeniería no siempre es un objetivo consciente. Por supuesto, si tu CIO es bastante harto de ver todos los años un comercial que le anuncia:

• que se va a poner fin a tal software o esta plataforma y
• la necesidad de comprar un nuevo software y
• iniciar un proyecto de implementación con sus consultores, todos muy expertos pero tampoco muy baratos, y
• la necesidad de actualizar su infraestructura de TI con el fin de mantener un nivel aceptable de rendimiento para esta nueva plataforma de software y
• nuevos precios en aumento, pues

tu CIO podría considerar un salto a una nueva tecnológia para reponer la mano sobre su entorno de TI y que dejan de tratarle como la gallina de los huevos de oro.

Sin embargo, he visto muchos casos en que la reingeniería no estaba previsto al principio, pero se ha convertido en una opción necesaria e inevitable después de una serie de descubrimientos, reflexiones y decisiones más o menos formalizadas.

Reingeniería del portafolio de aplicaciones

Hice una auditoría para un banco, o más bien su división de Asset Managemet que se ocupa de la gestión de activos financieros, por una aplicación que tenía que multiplicar por tres el número de clientes. ¿Quién dice tres veces más usuarios también dice tres veces más datos, y tres veces más (en promedio) conexiones a una base de datos tres veces más grande. De ahí surgío una preocupación para el rendimiento. La primera reacción del banco fue buscar una herramienta de pruebas de rendimiento y carga, y luego comenzaron a preguntarse si era posible detectar en el código algún defecto que pudiera poner en peligro el tiempo de respuesta en el futuro.

Si recuerdo correctamente, era una aplicación Visual Basic, y por las razones habituales de confidencialidad, ellos no querían entregarme todo el código de su aplicación. Esto es siempre un problema porque menos código tienes, menos defectos en el código encontramos y más difícil de demostrar el valor que puedes aportar.

Así que les propuse analizar un módulo de esa aplicación, pero también un poco de código J2EE y de código Cobol, con el objetivo principal de centrarme en la identificación de riesgos potenciales para el rendimiento, y un segundo objetivo de medición de mantenibilidad. Que no les interesó tanto, realmente tuve que insistir. Pero cuando presenté los resultados, se quedaron bastante impresionados, y alguien dijo « tenemos que presentar eso al CIO. »

De hecho, además de su interés por el rendimiento en esta aplicación, el CIO tenía sobre todo una preocupación de renovación de su portafolio de aplicaciones, que a su juicio estaba lleno de aplicaciones no siempre muy críticas, pero a menudo no muy mantenibles, y sin saber por dónde empezar. Tuvimos una segunda reunión en la que él participó, y en la que construimos casi en tiempo real un plan de refactorización de la aplicación Cobol y una reingeniería de la aplicación Visual Basic.

Conclusión: algunos casos de uso pueden dar lugar a una refactorización o una reingeniería que no fuera inicialmente un objetivo. Se requiere un análisis y la medición de la calidad del código para saber qué aplicaciones del portafolio de aplicaciones se beneficiarán de una reingeniería, y por dónde empezar.

Reingeniería de herramientas caseras

A veces la reingeniería se realiza simplemente en una parte de la aplicación. A principios de los años 90, con la aparición del Client-Server y las primeras aplicaciones con interfaz gráfica en Windows, muchas empresas desarrollaron su propio middleware para los intercambios asíncronos (o no) entre el mainframe y esas nuevas aplicaciones. Un equipo dedicado era responsable del desarrollo y del mantenimiento del middleware, entregando regularmente las correspondientes APIs y la documentación que permitían su uso por los equipos de proyecto.

El problema es que, como cualquier aplicación, ese código acumulaba deuda técnica, y el mantenimiento de esa herramienta se hacía cada vez más pesado, con correcciones y cambios requeridos por los proyectos más costosos, la documentación más difícil de mantener, y el conocimiento de la aplicación que se pierde a medida que el equipo se iba a otros puestos o simplemente de la empresa. Así que llegó un momento en que este middleware casero dio paso a una herramienta tipo MOM, ESB, EAI, o incluso una nueva arquitectura SOA o EDA (2). ¡No, no me pidas definiciones, ya dije al principio de este post que este blog no es un diccionario!

Por supuesto, había que encapsular esta nueva herramienta en las APIs existentes para minimizar el impacto en las aplicaciones. Como el middleware casero era más a menudo programado con un tipo de lenguaje 3GL, pero también, hay que decir, dado el entusiasmo del equipo de middleware para las nuevas tecnologías, muchas de estas APIs se han reescrito a menudo con programación Orientada a Objetos.

Reingeniería y interfaces de usuario

Un caso muy común de reingeniería: aplicaciones con una interfaz de usuario anticuada u obsoleta. Esto fue el caso de muchas aplicaciones de mainframe con una interfaz de caracteres, que había que llevar (no sin dificultad) a Windows. Incluso se encontraban herramientas para la generación automatica de pantallas gráficas desde las de mainframe, con algunos resultados divertidos (excepto para los usuarios finales).

La burbuja Internet y los sitios web han causado mucho daño en el cumplimiento de las normativas de interfaz gráfica. Ahora, con las aplicaciones para el smartphone, nos encontramos de nuevo con estas normas, pero con un término más moderno de UX (experiencia de usuario). Así que muchas aplicaciones están experimentando una reingeniería de la capa de presentación para ser accesibles tanto en la web como en tu móvil.

Los editores de software también deben realizar este tipo de proyecto con bastante frecuencia. Una interfaz HTML obsoleta es un verdadero peso muerto cuando se trata de vender un software y requerirá un ‘relooking’ con nuevas tecnologías: Flex o HTML5 por ejemplo.

Esto a veces causa problemas. Intenta seleccionar una o más filas de una tabla Flex para hacer un Copiar/Pegar: los usuarios tendrán problemas para entender que se ha adoptado una nueva tecnología que no permite estas operaciones básicas.

A menudo, un editor de software no va a interpretar la evolución de la interfaz gráfica como una reingeniería, sino simplemente como una nueva versión de su software con pantallas más bonitas. Si lo hacía, si él lo reconocería como un objetivo claro de migración a una nueva tecnología y a una interfaz gráfica diferente, podría tal vez considerar los impactos a los usuarios y los procedimientos en lugar de esperar que ellos los descubren cuando ya es demasiado tarde.

Perimetro

Como podemos ver a través de los ejemplos anteriores, es importante tener objetivos claros e incluso formalizados con el fin de evitar consecuencias no deseadas. Sobre todo porque estos objetivos condicionarán la siguiente pregunta: ¿reingeniería al equivalente, es decir, con las mismas funcionalidades, o con nuevas características?

Una reingeniería es a menudo un proyecto complejo que requiere un buen conocimiento de la aplicación y de las partes de código más difícil de leer y entender, una buena experiencia de la nueva plataforma de destino o del nuevo lenguaje, una estimación precisa de la deuda técnica con el fin de proceder a una evaluación adecuada del esfuerzo y de la planificación, un mínimo de documentación y si es posible, de cobertura de pruebas.

Como no suele ser a menudo el caso, el equipo del proyecto prefiere limitar los riesgos de fracaso del proyecto y evitar la introducción de nuevas funciones en la aplicación. Ahora los usuarios probablemente serán muy insistentes en este punto, ya que de lo contrario, no sólo van a tener que esperar el fin de la reingeniería, sino también el desarrollo de una nueva versión que incorpora las nuevas características que ellos desean.

Por desgracia para el equipo del proyecto, es a menudo los usuarios que van a ganar, simplemente porque es imposible escribir de nuevo una aplicación sin encontrar problemas técnicos que necesitarán nuevos procesos y/o rediseño de las funcionalidades de negocio.

Por ejemplo, si cambias la interfaz de usuario, es probable que cambian los datos que se muestran en la pantalla. ¿Cuántas veces he visto, durante una reingeniería, múltiples pantallas sustituidas por una sola pantalla compuesta por varias pestañas (el sindrome del ‘lo quiero todo y lo quiero ahora’)? Obviamente, se debe entonces modificar los tratamiento a la capa de datos, lo que puede causar problemas de rendimiento. Si no es posible arreglar estos problemas desde un punto técnico (con una actualización de la infraestructura técnica, por ejemplo), entonces se necesita pedir a los usuarios si sería posible llevar a cabo esta operación de negocio de otra manera, con el fin de cargar menos datos dentro de la pantalla.

Otro caso a considerar: una reingeniería no trata solamente del código y de los tratamientos, sino también de los datos. Un nuevo diseño de clases y programas tendrá como consecuencia los cambios correspondientes en las estructuras de datos.
Si un programa único accede a una tabla monstruosa en la base de datos, se requiere dividir este programa y esta tabla en entidades de más pequeña granularidad para una mejor capacidad de mantenimiento y, probablemente, un mayor rendimiento.

También se aprovechará de la reescritura de la aplicación para modificar determinados tipos de datos. Debido a que el usuario ya ha pedido algunas evoluciones, como cambiar el tamaño de un campo o la precisión de algunas cifras. O somos nosotros que iremos a preguntarle si realmente él necesita un campo de comentarios tan largo cuando casi nunca se utiliza.

Pues para un plan de proyecto de reingeniería:

• Planificar bien el rediseño de los tratamientos como también de los datos.
• Augurar de los cambios en los procesos de negocio.
• Incorporar uno o más usuarios al proyecto de modo que estén disponibles para cualquier cuestión de proceso, de tratamientos de negocio o de reingeniería de datos.
• No descartar todas las peticiones de cambios funcionales, pero estudiar bien aquellos que puedan afectar el proyecto o ser llevado fácilmente.

Y, sobre todo, siempre estar al tanto de los objetivos de la reingeniería.

1. Tetrapilectomie Incisión de pelos en 4. Neologismo inventado por Umberto Eco y su grupo de pataphysicians. Formado a partir del prefijo griego tetra (‘cuatro’), del latino pilus (‘pelo‘) y -ectomie (corte, incisión).
Significación: Tener un cuidado excesivo en una actividad inútil.

2. MOM : Message Oriented Middleware. ESB : Enterprise Service Bus. EAI : Enterprise Application Integration. SOA : Service Oriented Architecture. EDA : Event-Driven Architecture.