Hacia la modificación de sistemas heredados.

Muchas veces como informáticos pensamos que la mejor solución a los sistemas heredados es rehacerlos completamente. Ocurren casos en que sistemas que nosotros mismos hemos desarrollado creemos que no vale la pena modificarlos ya que no tienen las mejores prácticas que aprendimos desde que dejamos de trabajar en ellos. Por esto es tan importante aplicar buenas prácticas de desarrollo para permitir la mantención de estos sistemas.

Es cierto, nadie quiere trabajar con sistemas heredados. Es mucho más entretenido y motivante trabajar con un proyecto desde cero, donde podemos aplicar todos nuestros conocimientos y energías en crear un sistema que entregue valor al negocio, al menor costo posible y con buenas prácticas para que pueda ser mantenido en el tiempo. Pero la mayoría de las veces nos encontraremos con sistemas con una gran data desde su creación. En él han pasado muchas manos, muchos distintos desarrolladores, analistas, jefes de proyecto, diseñadores, arquitectos, etc. Es una gran labor el poder mantener un control correcto de un código que ha pasado por tantos diversos estilos de programación, sin perder el objetivo principal.

Hace unas semanas vi un artículo en el sitio de Martin Fowler sobre una analogía entre los matapalos y la evolución del software heredado. En él, comentaba cómo estas raíces crecían sobre un árbol para finalmente terminar matándolo, posándose sobre él para alcanzar la luz solar.

Matapalos

La metáfora le sirvió para describir una forma para reescribir un sistema: crear gradualmente un nuevo sistema alrededor de los bordes del antiguo, dejándolo crecer durante el tiempo hasta que el antiguo sistema es ‘estrangulado’ (estos árboles son conocidos en inglés como ‘strangled fig’, o ‘vids estranguladoras’).

En la empresa donde trabajo existe mucho código desarrollado en COM y ASP clásico. Uno de los objetivos internos del área es migrar estas tecnologías hacia .Net o similar. Esto, sobre todo por las arquitecturas de los computadores que se utilizan: el desarrollo de COM hasta donde sé sólo llegaba hasta Windows XP (en Windows 7 se puede, pero con ciertos hacks) y desde hace algunos meses Microsoft dejó de dar soporte a esta versión de Windows. Sin embargo, se debe tener claro que no es uno de los objetivos principales de la empresa ya que estos sistemas han funcionado durante muchos años, y seguirán así. Los objetivos de negocio son lo más importante, para darle valor agregado a este. ¿Cómo podemos compatibilizar esta necesidad con los objetivos de la empresa? ¿Es perentorio hacer una detención temporal para poder replantear la arquitectura y los códigos, cosa de darle oxígeno al software para lo que viene en los próximos años? Ciertamente, no se puede detener para replantear.

Aplicando la analogía de los matapalos, podemos pensar cómo plantear el objetivo de migrar de a poco. Una fórmula para sacase la COM de encima sería haciendo una dll .Net COM visible para que el ASP no note la diferencia. En el caso de llamadas que devuelvan ADO, hacer la traducción. Otro caso sería las aplicaciones Web: usando estructuras más semánticas para el sitio, evitando la sobrecarga en red por el abuso de tablas en la interfaz.

No obstante lo anterior, es importante destacar la regla principal de la mejora sobre sistemas heredados: si un sistema heredado cumple su función a cabalidad, es mejor práctica mantener el sistema tal cual está, entregando valor agregado con tecnologías y métodos de desarrolo actualizados a nuevas funcionalidades, por sobre la reimplementación desde cero. El costo de reimplementar desde cero es demasiado alto y no entrega valor agregado al negocio sobre el cual se sustenta el software.