h1

Sobre la arqueología de software

01/05/2011

Wizdoc [Icon By Buuf]  Tips & Tricks.

En serio, a veces siento que debo ponerme un sombrero de Indiana Jones y empezar a exclamar: “¡Ahora, aquí tenemos una excelente muestra de principios de la dinastía ‘Mike’! ¡Cuidado, puede matarte si la tocas!”

En estas semanas nuestro equipo de trabajo ha estado recibiendo el código de una solución empresarial que originalmente fue concebida y programada en los Estados Unidos. Ahora que el líder técnico y “papá” de dicho proyecto está buscando nuevos horizontes, la entrega hacia México está tomando fuerza. Es posible que la semana próxima tengamos que hacer un viaje a San Diego para revisar algunos puntos de este traspaso de conocimiento antes que dicha persona parta sin dolor a finales de este mes.

Una situación peliaguda es que así como la gran mayoría de sistemas que cambian de manos para su soporte y mantenimiento, éste tiene una escasa y pobre documentación, los desarrolladores originales ya no están y por supuesto, hay mucho más que hacer con la plataforma como corregir problemas de desempeño o ir acomodando nuevos requerimientos de nuestros stakeholders. Muchos se las ven negras debido a esto, ya que ocurre el típico “aquí está el código y cómo instalarlo; lo demás lo aprenderás sobre la marcha”. Sin embargo, para ahorrarnos sangre, sudor y lágrimas estaremos echando mano de una disciplina relativamente madura de la ingeniería de software que nos puede ayudar a resolver este tipo de situaciones: la arqueología de software.

La arqueología de software es el estudio de pobremente documentadas implementaciones de software legado, formando parte del mantenimiento de software. Nombrada por analogía con la arqueología convencional, es una metodología usada para realizar ingeniería inversa y aplicación de herramientas y procesos sobre piezas de software existente para extraer y entender su estructura y diseño. Todo ello para comprender exactamente qué se tiene en términos del código sobre el que se va a trabajar y encontrar patrones de diseño y desarrollo que puedan ser cosechados para desarrollos futuros.

En términos más humanos, se trata de “rascarle” al código para encontrar la arquitectura original, el diseño y las áreas de oportunidad que debemos resolver al tomar las riendas del sistema. La ventaja de este enfoque es que se debe seguir un proceso metódico para obtener la información que necesitamos; la primera vez que se le definió formalmente fue en la Conferencia OOPSLA (Object-Oriented Programming, Systems, Languages & Applications – Sistemas, Lenguajes y Aplicaciones Orientados a Objetos) celebrada durante el 2001 en Tampa Bay, Florida. Ahí se realizó un taller enfocado a “…permitir a los programadores hacerse cargo rápidamente de sistemas de software de gran tamaño que nunca antes habían visto”. Algunos años después, Mike Rozlog, gerente de producto en soluciones Delphi para Embarcadero Technologies refinó el término, publicando un sencillo proceso compuesto por seis pasos, enumerados a continuación:

1. Visualización. Obtener una representación visual del diseño de la aplicación. Es decir, a través de herramientas de ingeniería inversa debemos obtener un diagrama de clases para identificar dependencias entre objetos. Posteriormente debemos realizar esta misma conversión a los métodos localizados en la aplicación, para obtener un diagrama de secuencia que nos permita conocer el proceso de ejecución. Personalmente creo que a Rozlog le faltó algo fundamental para realizar nuestra labor: los diagramas de arquitectura y despliegue. Esto porque en el mundo moderno de las arquitecturas de N-capas, distribuidas u orientadas a servicios, no todo se encuentra en el código ya que pueden existir stored procedures o llamadas a servicios web de un tercero para recuperar o procesar información; de la misma manera podemos detectar dependencias que no necesariamente pueden verse reflejadas en un diagrama estático. Así, tendremos los siguientes artefactos después del primer paso:

  • Diagrama de arquitectura tecnológica (físico, lógico, de red, de aplicaciones)
  • Diagrama de clases
  • Diagramas de secuencia

2. Violaciones de diseño. Una vez que se ha obtenido la visualización del sistema y ésta ha sido revisada, deberemos hacer una inspección del diseño. Esto se realiza mediante métricas de calidad de software que incluyan cobertura, complejidad ciclomática o violación del principio del menor conocimiento. Los artefactos resultantes son:

  • Matriz de dependencias
  • Análisis de cobertura
  • Tabla de métricas de calidad de software

Esto es para detectar áreas de oportunidad que deberán ser corregidas por un programador de buen nivel.

Project @ XDepend

XDepend, en modalidad de matriz de dependencias, para encontrar áreas del código potencialmente problemáticas. (Click en imagen para ver a mayor escala)

3. Violaciones de estilo. Como parte complementaria a la revisión de diseño, es necesario encontrar problemas de estilo como valores hardcodeados o el uso indiscriminado de instrucciones System.out.println. La detección temprana de estos detalles ayudará a iniciar la limpieza del código y en algunos casos, a mejorar su desempeño. En la actualidad una gran cantidad de herramientas pueden realizar este tipo de revisión, como RefactorIT o el humilde checkstyle. El principal artefacto resultante de esta tarea es:

  • Listado de violaciones de estilo

4. Lógica de negocio. Ya que hemos comprobado si la llanta está desinflada o le falta aceite al motor, es necesario manejar el automóvil en carretera para ver cómo se comporta: comprobando el flujo de la aplicación podremos ver si existen problemas en tiempo de ejecución. Una manera de saberlo es mediante la automatización de pruebas unitarias en conjunto con pruebas de cobertura que nos dejen ver la interacción entre los diferentes componentes arquitectónicos. Si los desarrolladores fueron meticulosos y crearon una suite de pruebas mediante JUnit tenemos la mitad de la batalla ganada; de lo contrario será indispensable generar toda una suite de pruebas basada en el comportamiento de la plataforma. Por otro lado, para correr el sistema es necesario instalar un ambiente de ejecución lo más parecido al ambiente productivo, pues así serán identificadas las últimas dependencias del sistema como variables de entorno o archivos de internacionalización:

  • Ambiente de ejecución de pruebas integrales
  • Suite de pruebas unitarias
  • Resultados de pruebas de cobertura

5. Desempeño. Como hemos explicado en anteriores posts, más del 85 por ciento de las compañías presenta problemas de desempeño en sus aplicaciones. Por ello, es necesario incluir pruebas de este tipo durante el proceso que estamos llevando a cabo. El Wait-Based-Tuning es una buena metodología para realizarlo y aunque Rozlog sólo menciona que el 5% del código será el que nos esté poniendo el pie, generalmente hay tres lugares donde hay que buscar por áreas de oportunidad: la base de datos (índices, columnas, tablespace), la máquina virtual de java (garbage collector, permspace, memoria asignada) y llamadas a fuentes de datos (servicios web, DAOs y EJBs). El documento resultante de nuestra labor:

  • Análisis de desempeño

6. Documentación. Rozlog es poco específico al respecto, indicando que sería genial si todo este trabajo fuera capturado para uso futuro. Sin embargo, no indica QUÉ documentos deberían incluirse. En la vida real, son necesarios los siguientes documentos que conforman el principal entregable después de nuestra “excavación”:

  • Documento de arquitectura tecnológica
  • Documento de definición de base de datos
  • Documento de modelo de diseño
  • Lista de acciones a tomar (incluyendo correcciones y tareas no funcionales).

Al final del proceso el equipo debería tener una visión general de qué componentes integran la plataforma y cómo deben ser desplegados y configurados para funcionar correctamente. Adicionalmente, se habrán localizado los principales puntos de falla que impactan el funcionamiento y rendimiento del sistema; Rozlog los llama las “secciones tenebrosas del código”. Finalmente se tendrá una buena lista de Santa Claus o backlog con los siguientes pasos a seguir, que podrán ser implementados como parte del mantenimiento de la aplicación o como un proyecto aparte.

Compartiendo experiencias desde las trincheras

Algunos autores nos animan a no sólo estudiar la arquitectura del sistema, sino también a explorar sus inicios y razón de ser, incluyendo la historia del repositorio de versiones o contactar a los participantes del desarrollo original para entender cuál era la intención inicial de la plataforma y cómo se llegó a la versión que estamos recibiendo. Aunque esto es poco común, debemos intentarlo pues facilita descubrir situaciones como que “este modulo fue pensado como una demo, no para un ambiente productivo” y tomar cartas en el asunto.

Así, con información recopilada a través de medios formales e informales como herramientas de auditoría o tomarse una cerveza con el ex-desarrollador en jefe, encontraremos la manera de salir del laberinto al descubrir cuatro propiedades fundamentales del sistema heredado: estructura, comportamiento, contexto y propósito; mejorando nuestras posibilidades de llevar correctamente nuestra misión de soporte y mantenimiento de un sistema complejo.

Cheers!

Alguna vez mi ex-profesor de la universidad, el estimadísimo Dr. Gerardo Ayala, me aseguró que es más probable cerrar un negocio en una cantina que en una sala de juntas. Esto es una gran verdad y para este caso un par de chelas o una salidita al pelódromo más cercano nos pueden evitar caer en una trampa mortal. (Fuente de la imagen: mens-night.com)

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: