¿Reescribir o Refactorizar? Cómo Mover de Forma Segura Aplicaciones Legacy a Frameworks Modernos

Hola a todos. ¿Reescribir o refactorizar? Hoy voy a hablar sobre algo que muchos equipos enfrentan, pero pocos se preparan para ello. Qué hacer cuando tu frontend se convierte en legado, y cómo migrarlo de manera segura. Soy Sylwia Laskowska, desarrolladora de software senior en Atos. Actualmente estoy trabajando en un gran proyecto distribuido para la Comisión Europea. Soy de Gdansk, Polonia. Puedes visitar mi blog donde puedes leer más sobre migraciones de frontend y muchas, muchas cosas más.

Y esta no será una charla tutorial. Durante mi carrera, tuve muchas oportunidades de ver algunos, digamos, códigos históricamente interesantes y darles una segunda vida. Migré aplicaciones de Backbone a Vue, de Old Angular a Modern Angular, de ASP.MVC.NET a Modern Frameworks. Y honestamente, después de algún tiempo, puedes comenzar a ver los mismos patrones de migración en todas partes. Y por cierto, tengo mucha experiencia con legado.

Creé mi primer sitio web en 1999. Se ve de alguna manera así. HTML para uno, un libro de visitas, contador de visitas, conjuntos de marcos, que en ese entonces eran el mayor logro del diseño web. Sin CSS, pero ¿quién necesita CSS cuando puedes tener nieve JS cayendo en invierno? Así que este era perfecto y nunca lo migraría. Y en ese entonces pensé que este era el pico de la ingeniería de software.

nunca lo migraría. Y en ese entonces pensé que este era el pico de la ingeniería de software. Pero luego tuvimos BackboneJS, KnockoutJS, y fue como, wow, finalmente, UI interactiva, validación de formularios del lado del cliente. Se sentía como el futuro de la web. Y luego tuvimos ECMAScript 6, TypeScript, Modern Frameworks, y de repente este futuro se convirtió en legado. Nuevamente.

Porque la verdad es que todos terminaremos con legado, tarde o temprano. Esto se debe a que la tecnología envejece más rápido que las necesidades del negocio. Y legado no siempre significa antiguo o exótico. Puede ser tecnología perfectamente normal, solo lo suficientemente antigua como para dejar de escalar. Por ejemplo, versiones antiguas de bibliotecas populares. Y por supuesto, nadie planea para el legado. Tal vez el proyecto fue pausado por seis años. Tal vez nadie tiene tiempo o presupuesto para actualizaciones.

O tal vez el único desarrollador que quedaba en la empresa se fue en 2020. Así que pase lo que pase, todos terminaremos aquí. Lo que nos lleva a la pregunta, ¿por qué migrar en absoluto? Porque a veces los propietarios de productos me preguntan, si funciona, ¿por qué migrar? El desarrollador solo quiere algunas cosas brillantes en sus CVs. Siempre respondo, sabes, que no soy fanático de ningún framework en particular. Para mí, son herramientas como martillos. Pero cuando trabajo, quiero usar un buen martillo confiable. No el oxidado con piezas faltantes. Pero la migración no se trata solo de la experiencia del desarrollador. En primer lugar, seguridad.

Porque estas aplicaciones a menudo viven mucho más tiempo del planeado originalmente. Y ningún propietario de producto dijo jamás, está bien, sacrifiquemos la seguridad porque necesitamos más características. Al menos eso espero. También las herramientas. Así que herramientas modernas, paquetes más pequeños, vistas amplias significan una aplicación más rápida. Y una aplicación más rápida significa clientes felices. Bibliotecas e integraciones. Si tienes una biblioteca de terceros en tus proyectos, que no se ha actualizado en cinco años, parece que incluso el autor se olvidó de ella. Y no compila o no en un viejo 18. Eso no es código funcional. Esto es una bomba de tiempo. Y mi punto favorito, la deuda técnica tiene intereses. Y cuanto más esperas, más alto es el costo de la migración. Por eso la migración no se trata de moda. Se trata de la supervivencia de tu producto.

Cómo migrar, básicamente tenemos dos estrategias de migración. La primera es la estrategia Big Bang, reescribes la aplicación desde cero o más a menudo hoy en día, haces una gran actualización de una versión antigua de la biblioteca a la última. Por ejemplo, de React con clases a React moderno con hooks y suspense. También tenemos la estrategia incremental, donde reescribes pieza por pieza mientras entregas características entre medio. Y la que elijas debería depender de la realidad, no de la preferencia, porque los desarrolladores a menudo tratan la estrategia de migración como un debate filosófico. Pero usualmente las restricciones de tu proyecto toman la decisión por ti de todos modos.

Si recuerdas solo una diapositiva de esta presentación, que sea esta. ¿Cómo decidimos qué estrategia de migración deberíamos usar? La primera pregunta debería ser, ¿puedes dejar de entregar características por semanas o incluso meses? Si es así, puedes intentar la estrategia Big Bang. Si no, ya estás en el enfoque incremental. Además, Big Bang funciona mejor con proyectos pequeños o medianos. Si trabajas en un proyecto realmente grande, Big Bang y congelar características simplemente lo matarían. ¿Cómo es tu equipo? Si tu equipo está compuesto principalmente por desarrolladores senior o intermedios, Big Bang es posible. Pero si tienes muchos juniors en el equipo, es mejor ir con la estrategia incremental porque pueden aprender mientras tanto. ¿Quieres un rediseño completo de la UI? Será mucho más fácil con Big Bang porque en una estrategia incremental, dos UIs necesitan coexistir por mucho tiempo. Nivel de documentación.

Si tu proyecto está mal documentado con muchos casos límite desconocidos, es mejor optar por incremental debido a la estrategia de reversión más fácil. Por último, pero no menos importante, la seguridad. Si tu aplicación no cumple con la seguridad, Big Bang puede ser la única opción para ti. Hablemos un poco más sobre la estrategia Big Bang. En la literatura, a veces leerás que Big Bang es arriesgado, un patrón de último recurso, incluso un anti-patrón. Y es totalmente cierto cuando hablamos de un monolito Java de 20 años. Mejor no tocar nada. Pero nuestras aplicaciones front-end son generalmente relativamente pequeñas y relativamente modernas. Y a veces es simplemente más barato y rápido optar por un Big Bang, especialmente cuando no hablamos de una reescritura completa, sino de una actualización de versiones antiguas de bibliotecas modernas a sus últimas versiones.

Debo admitir que me gusta la estrategia Big Bang. Sí, necesitas congelar el desarrollo de características durante semanas o meses. Pero luego terminas con una arquitectura más limpia, herramientas modernas, sin restos de legado, una vida más fácil durante las auditorías de seguridad y un estado limpio para futuras actualizaciones. E incluso en el diagrama, parece bastante simple. Haces una auditoría y planificación, luego congelas el desarrollo de características. A continuación, realizas el trabajo de migración. Luego tienes una fase de integración y pruebas. Y luego sales en vivo con, por supuesto, algún plan de reversión. Suena bien, ¿verdad? E incluso cada migración parece simple en los diagramas de arquitectura. Bueno, la realidad no es tan romántica, lo que nos lleva a la primera historia de la vida real.

Fue una migración de Angular 7 al Angular moderno. Y esta aplicación ya estaba en producción, pero en modo de mantenimiento. Nadie la actualizó durante años. De repente, los interesados decidieron extenderla significativamente y agregar muchas características nuevas. Y los alentamos a migrar al último Angular primero, principalmente por razones de seguridad. Éramos un equipo de cuatro desarrolladores, y la migración nos llevó unos cuatro meses, junto con la estabilización y la corrección de errores. No quiero profundizar en los detalles técnicos de la migración porque variará en tus proyectos. Lo que quiero decirte es cómo se veía realmente para que puedas aprender de mis errores, no de los tuyos. Así que, en primer lugar, es fácil subestimar. Y escuché muchas veces, Sylwia, ¿por qué lleva tanto tiempo? Porque parece fácil. Solo actualiza Angular.

Y sí, esa parte fue fácil. Pero el ecosistema alrededor de esto no lo fue. Aquí es donde comienza el verdadero dolor. Por ejemplo, la biblioteca de UI que usamos cambió su sintaxis significativamente, en algún lugar entre la versión 12 y 13. Imagina la cantidad de plantillas que tuvimos que ajustar. Bien, ahora teníamos agentes de codificación para ayudarnos. Pero aún tienes que pasar mucho tiempo controlando los detalles. Por supuesto, teníamos algunas bibliotecas desactualizadas incompatibles con Angular moderno. Así que tuvimos que reemplazarlas de alguna manera.

Además, la sintaxis de NGRX cambió, mientras tanto, por lo que otros 100 lugares tuvieron que ser ajustados. Y sí, teníamos muchas pruebas end to end, y el 80% de ellas fallaron debido a nuestros cambios en la biblioteca de UI. Así que bueno, trabajo adicional para el equipo de QA. Vale la pena mencionar que tuvimos una corrección urgente en producción durante la migración. No fue un problema en absoluto debido a nuestra clara estrategia de ramificación. Pero puedo imaginar un equipo que se lanza por completo, y entonces estarás condenado. Al final, la migración fue un gran éxito.

Tuvimos compilaciones dos veces más rápidas, un paquete un 20% más pequeño, los informes de seguridad finalmente se pusieron en verde. Y lo que es más, la biblioteca de UI en la versión moderna era mucho más bonita y accesible. Así que incluso los interesados más resistentes a la tecnología decían, ah, migración, sí, ahora veo que se ve mucho mejor, lo cual fue bastante divertido para mí. Y por supuesto, teníamos un estado limpio para futuras actualizaciones, e incluso el equipo de QA, que al principio nos odiaba, ahora admite que las actualizaciones deben hacerse regularmente, no una vez cada siete años. Pasemos ahora a la estrategia de migración incremental, que en muchos proyectos es la única opción realista.

A diferencia del enfoque big bang, no necesitas congelar el desarrollo del producto completamente. El equipo puede continuar lanzando características mientras la migración ocurre en segundo plano. Y generalmente incremental significa el patrón de diseño strangler. También hay otros patrones de diseño incremental.

También hay otras estrategias incrementales, pero strangler es el patrón más común y elegante, además, utilizado por muchas grandes empresas. Así que está probado en batalla. Bien, ¿cómo funciona?

Como ves en mi hermoso diagrama, tienes tu aplicación heredada, construyes tu nueva aplicación en el sitio, también construyes el proxy inverso, luego reescribes pantalla por pantalla, ruta por ruta, y el proxy inverso decide qué rutas redirigen a la aplicación heredada y cuáles a la nueva. Bien, el tiempo vuela, trabajas duro, tu nueva aplicación se vuelve más grande, la aplicación heredada comienza a encogerse. Idealmente, cada ruta migrada también elimina un poco de deuda técnica y te da algo de libertad para mejorar las herramientas de arquitectura, etc. Y eventualmente, con suerte, puedes deshacerte de la aplicación heredada y el proxy inverso y disfrutar de tu nueva aplicación brillante y nueva.

Veamos un ejemplo mínimo de un proxy inverso. Como ves, compartes el mismo backend, la misma autenticación, pero no el código frontend. Y honestamente, esta separación es muy importante porque una vez que las aplicaciones frontend comienzan a compartir demasiado código, las migraciones se vuelven mucho más difíciles de controlar y de repente la propia migración comienza a crear nueva deuda técnica. Si realmente necesitas que las aplicaciones frontend se comuniquen de alguna manera, es mejor hacerlo a través de eventos DOM personalizados. Evita los llamados adaptadores temporales, que por supuesto duran para siempre.

Y otra ventaja importante del patrón strangler, como ves en el ejemplo, puedes o incluso deberías usar feature flags para la reversión. Con una migración big bang la reversión puede ser estresante y complicada. Pero con el patrón strangler, la reversión es a menudo solo un cambio de feature flag. Entonces, si algo sale mal en producción, tienes una reversión instantánea a la versión heredada.

Veamos la historia de la vida real del patrón strangler. Esta era una aplicación antigua escrita en Backbone. La migración big bang era teóricamente posible, pero la empresa era una startup. Y un día, los stakeholders vinieron a nosotros y dijeron, hey equipo, acabamos de ver la característica que aún no tenemos, tienen tres meses para entregarla, diviértanse. Y yo estaba como, sí, divertido, de ninguna manera, lo estoy construyendo en Backbone. Sugerí la migración con el patrón strangler y los stakeholders estuvieron de acuerdo.

Eran personas inteligentes y sabían que era el momento adecuado para hacerlo. El equipo era yo y dos desarrolladores junior de Java, quienes juro escucharon la palabra TypeScript por primera vez en sus vidas. Afortunadamente, aprendieron rápido. Bueno, no tenían otra opción.

Primero, construí una nueva aplicación de vista en el sitio y el proxy inverso. Las primeras rutas que migré fueron la pantalla de inicio de sesión como prueba de concepto. Y por supuesto, la nueva característica brillante por la que el cliente ya había pagado. Luego migramos pantalla por pantalla, ruta por ruta, mientras lanzábamos características entre medio. Nos tomó más de un año, pero finalmente nos deshicimos completamente de Backbone.

Sin tiempo de inactividad, el cliente ni siquiera notó que la migración había ocurrido. Tuvimos una construcción cinco veces más rápida, un paquete significativamente más pequeño y un estado limpio para futuras actualizaciones. Pero el patrón strangler también tiene algunos inconvenientes. Primero, el tiempo, mucho más largo que durante la migración BigMac. Nos tomó más de un año. También existe el riesgo de una migración sin fin. Después de un par de meses, la gente tiende a olvidar que la migración aún está en curso. Y necesitas recordarle a tu product owner durante cada sesión de planificación, oye, estamos en medio de una migración.

Necesitamos sacrificar algunos story points para ello. Y no hay manera de no tocar el código heredado. No hay manera. Y los desarrolladores lo odian. Y escuché muchas veces, Sylwia, ¿por qué estamos complicando tanto esto? Ahora necesitamos conocer Backbone y Vue. Así que, cualquiera que sea la estrategia que elijas, siempre serás el chivo expiatorio. Pero no te preocupes, porque después de la migración, probablemente te convertirás en un héroe de la empresa.

Una migración fluida es un arte. Y muchas cosas pueden salir mal. Aquí están las trampas más comunes. En primer lugar, no tener un plan. A menudo escucho, vamos a migrar esto. Sí, vamos a migrar. Esto no es un plan. Necesitas una auditoría primero. ¿Cuántas pantallas tienes? ¿Cuántas pruebas end-to-end? ¿Cuál es la definición de hecho? Solo hay unas pocas preguntas importantes.

Además, nuevo framework, misma arquitectura. Recuerda que migrar no siempre significa refactorizar. Y si migras a ciegas un spaghetti, terminarás con un spaghetti moderno. Sin plan de respaldo. Siempre asume que algo saldrá mal en producción y asegúrate de tener una forma sencilla de volver atrás. Porque durante la migración, no solo estás cambiando la lógica de negocio, sino que a menudo también las herramientas, el proceso de construcción, el enrutamiento y las integraciones. Y algunos pequeños problemas pueden ser rápidamente muy visibles en producción.

Además, intenta no volcar seis meses de trabajo de migración en QA en un solo sprint. Te odiarán. Y honestamente, tendrán razón, porque las pruebas de migración deberían ocurrir de manera continua. De lo contrario, la fase de estabilización se vuelve dolorosa para todos los involucrados.

Así que siempre trata la migración como un producto, no como una misión secundaria. Necesita planificación, prioridades, comunicación, entrega regular, al igual que cualquier otra iniciativa empresarial importante. Porque si la migración se convierte en algo que hacemos al margen, eventualmente, nadie realmente se adueña de ella. Y así es como las migraciones terminan sin terminar durante años.

Bien. Algunas reflexiones finales. La migración es como comprar una casa antigua. No es tu culpa que esté en ruinas, pero ahora es tu responsabilidad renovarla. Y puedes tomarte un par de semanas libres y arreglar todo de una vez, así que esa es una estrategia de big bang. También puedes mudarte y renovarla habitación por habitación, como en Strangler pattern. La única mala decisión es no hacer nada. Entonces tendrás que migrar de todos modos, pero probablemente durante un incidente de producción. Gracias.