Uno de los impulsos más difíciles de reprimir para un programador es el de ver un código antiguo, de esos que los años han ido degradando, y no caer en la tentación de rehacer esa funcionalidad que se nota que tiene ñapa sobre ñapa, que se hace de manera ineficiente, que tiene cincuenta mil ifs anidados…
Por otra parte, cada cierto tiempo, las empresas se plantean realizar migraciones de aplicaciones antiguas a una tecnología más nueva. Los motivos esgrimidos suelen ser aprovechar una infraestructura que ha ido mejorando con el paso del tiempo, que puede soportar un mayor número de usuarios, o mayor carga de trabajo.
Sin embargo, el software de dichas empresas puede no haber crecido a la par, por ejemplo porque cuando se desarrolló la aplicación no había esas necesidades, y no se incluyeron como requisitos no funcionales.
Ese es el momento en el que, armados con todas las herramientas estupendas que tenemos a día de hoy, te encuentras con la «fácil» tarea de realizar la migración. Y ya que estamos, como hacer esa migración es «tan sencillo», pues ya aprovechamos y tenemos que incluir cierta funcionalidad que no tenía la aplicación original. Como todos sabemos, una migración es algo que «no produce valor añadido» – dicen – y claro, puede tener un cierto coste que, elevado o no, hay que justificar. Y de ahí el hecho de meterle «algo nuevo».
¿Quién no se ha encontrado con una situación así?
Tras realizar la migración, el resultado habitual, y que sorprende a muchos clientes, es el siguiente:
- La aplicación migrada suele tener más bugs que la original. Normalmente suele ser porque ese código tan feo suele cubrir los cincuenta millones de casos especiales que se presentan durante el proceso que cubre, y al que nadie hace caso en el momento de plantear la nueva solución. Generalmente, no es posible bajar al nivel del código para todo el sistema antiguo cuando se diseña el nuevo.
- El rendimiento de la nueva aplicación suele ser menor. Esto pasa más a menudo de lo que pudiera parecer, por ejemplo cuando se migra una aplicación en entorno host (cobol) a tecnologías actuales (Java – .NET). Cierto, la tecnología moderna te proporciona mucha más funcionalidad de base, pero a un cierto precio. Acelera el desarrollo, pero no necesariamente el rendimiento.
De ahí que surja la pregunta: ¿realmente es rentable hacer una migración de una aplicación desde cero?
Mi opinión es que depende. Hay situaciones en las que puede interesar migrar. Pero en la mayoría de los casos, puede ser interesante pensar en la reutilización de ese sistema, por ejemplo aplicando una arquitectura orientada a servicios. La nueva funcionalidad se puede desarrollar con otra tecnología más actual, y ciertas partes del sistema antiguo se pueden ir migrando paulatinamente.
Y vosotros, ¿qué opináis?
P.D.: Al hilo, un artículo muy interesante.