¿Reescribir o Refactorizar? Cómo Mover de Forma Segura Aplicaciones Legadas 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 senior de software en EITOS. Actualmente estoy trabajando en un gran proyecto distribuido para la Comisión Europea. Soy de Gdańsk, 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 base históricamente interesantes y darles una segunda vida. Migré aplicaciones de Backbone a Vue, de Old Angular a Modern Angular, de ASP.NPC.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 como esto. HTML 4.1, 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. 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, otra vez. 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 durante seis años. Tal vez nadie tiene tiempo o presupuesto para actualizaciones. O tal vez el único desarrollador dejó la empresa 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? Los desarrolladores solo quieren algunas cosas brillantes en sus CVs.

Siempre respondo, sabes que no soy un fanboy de ningún framework en particular. Para mí, son herramientas como martillos. Pero cuando trabajo, quiero usar un buen martillo confiable, no uno oxidado con piezas faltantes. Pero la migración no se trata solo de la experiencia del desarrollador. En primer lugar, la seguridad. Cuando la tecnología está desactualizada, los parches de seguridad se detienen y los informes de vulnerabilidad comienzan a ponerse rojos. Y los proyectos empresariales son especialmente vulnerables a esto porque estas aplicaciones a menudo viven mucho más tiempo de lo planeado originalmente. Y ningún propietario de producto ha dicho jamás, está bien, sacrifiquemos la seguridad porque necesitamos más características al menos eso espero.

También las herramientas. Así que las herramientas modernas, paquetes más pequeños, compilaciones blancas significan una aplicación más rápida. Y una aplicación más rápida significa un cliente feliz. Bibliotecas e integraciones. Si tienes una biblioteca de terceros en tu proyecto, que no se ha actualizado durante cinco años, parece que incluso un autor se olvidó de ella y no se compila o se conoce en un antiguo 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, mayor 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 más antigua de la biblioteca a la última. Por ejemplo, de React con clases a Modern React con hooks y suspense. También tenemos la estrategia incremental donde reescribes pieza por pieza mientras envías 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 tus restricciones del 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 durante 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 de nivel medio, big bang es posible. Pero si tienes muchos juniors en el equipo, es mejor optar por la estrategia incremental porque pueden aprender mientras tanto. ¿Quieres un rediseño completo de la interfaz de usuario? Será mucho más fácil con big bang porque en una estrategia incremental, dos interfaces de usuario necesitan coexistir durante 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 suelen ser 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 heredados, 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 ajustes, 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 entras en producción 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 ampliarla significativamente y agregar muchas características nuevas.

Y los animamos a migrar al último Angular primero, principalmente por razones de seguridad. Éramos un equipo de cuatro desarrolladores y la migración nos tomó alrededor de cuatro meses, junto con la estabilización y corrección de errores. No quiero profundizar en los detalles técnicos de la migración porque variará en sus proyectos. Lo que quiero contarles es cómo se veía realmente para que puedan aprender de mis errores, no de los suyos. Así que, en primer lugar, es fácil subestimar. Y escuché muchas veces, Sylwia, ¿por qué lleva tanto tiempo? Porque parece fácil, solo actualizar Angular. Y sí, esa parte fue fácil. Pero el ecosistema alrededor de esto lo hizo. 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. Imaginen 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, así que otros cien lugares tuvieron que ser ajustados. Y sí, teníamos muchas pruebas de extremo a extremo y el 80% de ellas fallaron debido a los cambios en nuestra 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 va con todo, 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 ademá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 incremental generalmente significa el patrón de diseño strangler. 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 probado en batalla. Bien, ¿cómo funciona? Como ves en mi hermoso diagrama, tienes tu aplicación heredada. Construyes tu nueva aplicación al lado. También construyes tu nueva aplicación al lado. 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 hace 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. Por supuesto, en proyectos empresariales, las soluciones temporales a veces sobreviven un poco más de lo esperado.

Pero incluso entonces, la migración incremental es a menudo mucho más segura y más realista que intentar reescribir todo de una vez. Veamos un ejemplo mínimo de un proxy inverso. Como ves, compartes el mismo back-end, mismo out, pero no el código del front-end. Y honestamente, esta separación es muy importante, porque una vez que las aplicaciones de front-end comienzan a compartir demasiado código, las migraciones se vuelven mucho más difíciles de controlar. Y de repente, la migración en sí comienza a crear nueva deuda técnica. Si realmente necesitas que las aplicaciones de front-end 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 revertir. Con una migración big bang, revertir puede ser estresante y complicado. Pero con el patrón strangler, revertir es a menudo solo un cambio de feature flag. Así que si algo sale mal en producción, tienes una reversión instantánea a la versión heredada.

Veamos la historia 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 interesados vinieron a nosotros y dijeron, hey equipo, acabamos de ver la función 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 interesados estuvieron de acuerdo. Eran tipos inteligentes y sabían que era el momento más adecuado para hacerlo.

El equipo era yo y dos desarrolladores junior de Java, quienes juro que 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 Vue al lado y el proxy inverso. Las primeras rutas que migré fueron la pantalla de inicio de sesión como prueba de concepto, y por supuesto, esta nueva función brillante que el cliente ya había pagado. Luego migramos pantalla por pantalla, ruta por ruta, mientras lanzábamos funciones entre medio. Nos tomó más de un año, pero finalmente, nos deshicimos completamente de Backbone.

Con cero tiempo de inactividad, el cliente ni siquiera notó que la migración ocurrió. Tuvimos una compilació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 algunas desventajas. En primer lugar, el tiempo, mucho más largo que durante la migración big mac. Nos tomó más de un año. También existe el riesgo de una migración interminable. Después de un par de meses, la gente tiende a olvidar que la migración aún está ocurriendo, 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 puntos de historia 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 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 suave es un arte, y muchas cosas pueden salir mal. Aquí están las trampas más comunes. En primer lugar, no hay plan. A menudo escucho, vamos a migrar esta aplicación. Sí, vamos a migrar. Esto no es un plan. Necesitas una auditoría primero. ¿Cuántas pantallas tienes? ¿Cuántas pruebas de extremo a extremo? ¿Cuál es la definición de hecho? Estas son solo algunas preguntas importantes.

Además, nuevo framework, misma arquitectura. Recuerda que la migración no siempre significa refactorización, y si migras a ciegas espagueti, terminarás con espagueti moderno. Sin plan de hoja de ruta. Siempre asume que algo saldrá mal en producción, y asegúrate de tener una forma sencilla de retroceder. Porque durante la migración, estás cambiando no solo la lógica de negocio, sino a menudo también las herramientas, el proceso de compilación, el enrutamiento y las integraciones. Y algunos pequeños problemas pueden ser rápidamente muy visibles en producción. Además, trata de 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 deben 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 fallas 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 un patrón strangler. 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.