Para empezar a modernizar una aplicación heredada, ponga por escrito por qué tiene que cambiar y evalúe a la vez el código y la producción. Estabilice el sistema y rodee de pruebas el comportamiento del que depende el negocio antes de cambiar su estructura. Con esa red de seguridad, sustituya el sistema pieza a pieza, migre los datos con método y reserve la reescritura completa para el raro caso en que poco merezca conservarse.
Identifique el motivo de negocio antes de tocar el código
Modernizar es caro, así que empiece por el motivo. Los más habituales son un entorno de ejecución o un framework que ha llegado al final de su vida útil, cambios que tardan semanas porque cada versión rompe algo, un sistema que solo entiende una persona o una plataforma que no puede soportar lo que el negocio necesitará a continuación. Cada motivo apunta a un primer paso distinto.
Ponga el motivo por escrito con una medida que pueda comprobar más adelante, como la frecuencia con la que publica versiones, el número de incidencias o el tiempo que tarda un cambio típico en llegar a los usuarios. Sin ella, la modernización se convierte en un proyecto técnico sin final, difícil de defender en la siguiente revisión del presupuesto.
Evalúe el código y la producción antes de decidir nada
Una evaluación le dice lo que realmente tiene. Hágala breve y que termine con un informe escrito y un primer paso recomendado. Lea el código, pero lea también la producción: registros, incidencias, consultas lentas y la forma en que se publican las versiones. Los peores problemas suelen estar alrededor del código más que en él.
- Versiones del entorno de ejecución, del framework y de las bibliotecas, y cuáles ya no reciben parches de seguridad
- Qué partes cambian más a menudo y cuáles fallan más, según el historial de versiones y el registro de incidencias
- La cobertura de pruebas en los recorridos de los que depende el negocio
- Cómo se compila, se configura y se despliega la aplicación, y quién sabe hacerlo
- El modelo de datos, su tamaño y qué otros sistemas leen o escriben en la misma base de datos
- Las personas que conocen el sistema, y lo que solo ellas saben
Estabilice primero la producción, para que el trabajo tenga una base firme
Si el sistema falla cada semana, la modernización se interrumpirá cada semana. Corrija primero lo que provoca incidencias: añada monitorización y alertas en los recorridos críticos, automatice la compilación y el despliegue para que las publicaciones sean repetibles, y saque los secretos y la configuración del código.
Estos pasos dan resultados de inmediato y hacen más seguro cada paso posterior. También muestran pronto si el equipo es capaz de cambiar el sistema sin romperlo, algo que conviene saber antes de comprometerse con un plan más amplio.
Cree una red de pruebas alrededor del comportamiento del que depende
El código heredado suele tener pocas pruebas, y su comportamiento documentado rara vez coincide con el real. Antes de cambiar la estructura, escriba pruebas de caracterización: pruebas que registran lo que hace hoy el sistema, incluidos sus casos límite extraños, para que cualquier cambio de comportamiento aparezca como una prueba fallida.
Empiece por los bordes, con pruebas que llaman a la aplicación a través de su API o de su interfaz de usuario y comprueban los resultados, porque resisten los cambios internos. Para cálculos e informes, vuelva a pasar entradas reales por el código antiguo y por el nuevo y compare los resultados. Añada pruebas más finas a cada parte a medida que la refactoriza. Nuestro artículo sobre la actualización de una aplicación Java 8 crítica muestra la misma red de seguridad aplicada a la actualización de un entorno de ejecución.
Sustituya el sistema pieza a pieza en lugar de reescribirlo
Una reescritura completa queda limpia sobre el papel, pero el sistema antiguo sigue funcionando y cambiando mientras el nuevo lo alcanza, y cada comportamiento no documentado hay que redescubrirlo por el camino. Por eso las reescrituras tardan tan a menudo más de lo previsto mientras el negocio espera.
La alternativa habitual es el patrón strangler fig (higuera estranguladora). Coloque una capa de enrutamiento, como un proxy inverso o una pasarela de API, delante de la aplicación heredada. Construya una funcionalidad cada vez en el código nuevo y dirija hacia él el tráfico de esa funcionalidad cuando esté probada. El sistema antiguo se reduce hasta que se puede apagar, y el negocio obtiene valor en cada paso.
Una reescritura puede seguir siendo la decisión correcta: cuando el código es pequeño y su comportamiento se entiende bien, o cuando la plataforma sobre la que funciona no puede mantenerse viva el tiempo suficiente para una sustitución gradual. Decida con criterios escritos, no por frustración.
Trate los datos como una migración en sí misma
El código se puede sustituir por partes; los datos son más difíciles de dividir. Mientras el código heredado y el nuevo comparten una base de datos, cada cambio de esquema hay que coordinarlo. Decida pronto qué sistema es la fuente de verdad para cada tipo de dato, y evite que dos sistemas escriban el mismo registro sin una regla que diga qué escritura prevalece.
Cuando se traslade una funcionalidad, traslade o sincronice sus datos con método: scripts de migración probados contra una copia de producción, o sincronización continua mientras funcionan ambos sistemas. Planifique cómo conciliará los dos, por ejemplo con recuentos diarios y sumas de verificación, y conserve la posibilidad de volver atrás hasta que las cifras cuadren.
Ordene el trabajo por riesgo y valor, y muestre avances pronto
Ordene el trabajo para que cada paso reduzca un riesgo o entregue algo que el negocio pueda ver. Una secuencia habitual es estabilizar y automatizar, añadir pruebas, actualizar el entorno de ejecución y después extraer las funcionalidades que más cambian. Las partes estables que apenas se tocan pueden esperar, a veces indefinidamente.
Mantenga un plan breve y revíselo después de cada paso, porque lo que aprenda cambiará el orden. Nuestros ingenieros han trabajado así en sistemas críticos. A través de Sopra Steria, dirigieron la migración de Java 8 a 16 de una aplicación crítica de trading intradía de gas, y como parte del equipo del programa cloud de Crédit Agricole evaluamos cada aplicación que migramos para decidir si actualizarla o reconstruirla. Si quiere una evaluación de su propio sistema, o un equipo que ejecute el plan, SDK Enterprises hace ambas cosas bajo un único contrato.
Puntos clave
- Ponga por escrito el motivo de negocio de la modernización, con una medida que pueda comprobar más adelante.
- Evalúe a la vez el código y la producción antes de elegir entre actualizar, sustituir gradualmente o reescribir.
- Estabilice la producción y rodee de pruebas de caracterización el comportamiento crítico antes de cambiar la estructura.
- Sustituya el sistema pieza a pieza tras una capa de enrutamiento, salvo que una reescritura sea claramente más pequeña y segura.
- Planifique la propiedad de los datos, su sincronización y su conciliación como una migración en sí misma.
Preguntas frecuentes
¿Debemos reescribir desde cero nuestra aplicación heredada?
Normalmente no. Una reescritura compite con un sistema que no deja de cambiar y tiene que redescubrir comportamientos que nadie documentó. Sustitúyala de forma gradual, salvo que el código sea pequeño y se entienda bien, o esté ligado a una plataforma que no se puede mantener en funcionamiento.
¿Cuánto se tarda en modernizar una aplicación heredada?
Depende del tamaño del sistema, de su cobertura de pruebas, de lo enmarañados que estén sus datos y de cuánto haya que cambiar. Una evaluación breve le da un plan realista y un primer paso lo bastante pequeño como para terminarlo y medirlo, en lugar de una sola fecha para todo el esfuerzo.
¿Podemos seguir lanzando funcionalidades mientras modernizamos?
Sí, y conviene hacerlo. La sustitución gradual permite al equipo entregar funcionalidades en el código nuevo mientras el sistema heredado sigue funcionando. Acuerde qué parte del tiempo del equipo se dedica a la modernización, para que el trabajo en funcionalidades no la absorba sin que nadie se dé cuenta.