Migración Compleja de React: Nuevas Soluciones a los Problemas de una Base de Código Antigua

Buenas tardes a todos, por supuesto, no a todos, solo a aquellos que están donde realmente es tarde, para todos los demás, sea cual sea la hora del día. Avísenme si han visto esto antes, ¿verdad? Imagina que tienes tu código heredado y no te está brindando toda la velocidad que necesitas, ¿verdad? El mundo ha cambiado, puedes sentirlo en tu estilo, puedes sentirlo en tu compilación, puedes olerlo en el código. Luego encuentras nuevas tecnologías y tu equipo está ansioso por adoptar eso. Todo es bastante sorprendente, puedes hacer cosas que antes no podías hacer y sí, excepto que no te resultan muy familiares. Dejas que tus equipos decidan qué usar. En algún momento, la mejor tecnología gana, todos están contentos y al menos puedes comenzar a entregar tus características. El negocio siempre lo hace, entregas, el negocio quiere cosas nuevas, cosas más brillantes, y en algún momento hay una pequeña discrepancia. Algunas tecnologías son diferentes aquí y allá, han aparecido diferentes formas de hacer las cosas, tu equipo crece, las características crecen y comienzas a ver discrepancias aquí y allá, pero al menos estás entregando y las cosas están evolucionando y creciendo. Avancemos rápidamente 10 años y tienes un nuevo código heredado. Mi nombre es Jason Santos y así solía vestir para impresionar a los clientes, quiero decir cuando realmente podías conocerlos cara a cara y trabajaba en Rainbow. Probablemente sepas quiénes somos y estoy aquí para hablarles un poco sobre las cosas increíbles que hicimos en asociación con ServingMonkey. Pero no te hagas la ilusión de que he hecho todas estas cosas yo solo, ¿verdad? Hay un grupo increíble, increíble de personas que me ayudaron mucho y que hicieron la mayor parte del trabajo en realidad, mientras solo te mantenían y se llevaban el crédito. Y en serio, son algunos de los ingenieros más fantásticos y más inteligentes con los que he trabajado.

Bueno, pero primero permítanme contarles un poco de qué trata esta presentación. Vamos a hablarles sobre qué es exactamente ServingMonkey, qué es Rango exactamente, y cuáles son los problemas a los que nos enfrentamos. Vamos a hablarles un poco sobre qué tipo de soluciones encontramos para resolver esos problemas. Y, por supuesto, les mostraré algo del código. Bien, ¿qué es exactamente este producto que estamos modernizando? ServingMonkey tiene uno de los primeros ejemplos de software como servicio en el mercado. Es un pionero del Valle del Silicio que ayudó a dar forma a esa industria. Tiene alrededor de 1,200 empleados y más de 17 millones de usuarios. Tienen líneas de productos que incluyen software líder en encuestas y todo tipo de investigación de mercado, como encuestas rápidas, análisis competitivo, retroalimentación de clientes, lo que sea. Tienen una gran presencia en empresas enterprise de todo el mundo y tuvieron un impacto masivo durante la pandemia de 2020. Empoderaron la comunicación entre empresas, el compromiso, todas esas cosas buenas que ahora nos vemos obligados a hacer desde nuestras cocinas. Sí, es genial tener un gran software para hacer eso. Ahora, para la autopromoción, Work4Rainbow, ¿verdad? Somos bastante conocidos en la escena del desarrollo de software. Fuimos pioneros en la web moderna y tenemos una presencia constante en cumbres como esta. Nuestro equipo se destaca en la creación de nuevos productos y en ayudar a las empresas a modernizarse y volverse más digitales. Probablemente nos conozcan. Hemos estado patrocinando y presentando en muchos eventos tecnológicos desde 2013, y somos una consultoría con sede en Toronto, Canadá, pero ahora tenemos presencia en varios países. En el último trimestre de 2020, Silver Monkey se asoció con Wrangell en un esfuerzo por modernizar algunas de sus bases de código en esta nueva plataforma tecnológica que estaban desarrollando. El equipo de Silver Monkey se enfrentaba a muchos desafíos para llevar a todos sus equipos de características a esa nueva plataforma web, y el mayor desafío podría ser el tamaño mismo de ella, y utilizaron la mejor tecnología que estaba disponible, y la estaban construyendo con algunas de las mejores y más maduras prácticas de DevOps que hemos encontrado. Parecía que estaban preparados para el éxito. Además, habían desarrollado este increíble sistema de design, muy cohesivo y completo, basado en sólidos principios de design, e implementado como una biblioteca de componentes de React con todo incluido, y la guinda del pastel. Sin embargo, ahora que necesitaban migrar, tenían grandes expectativas sobre lo que esa migración iba a lograr. Y juntos, Rangel y Sarumaki idearon algunos ajustes finos y parte de la planificación en torno a cómo se iban a lograr estos objetivos. Todo comenzó con la declaración del problema, ¿verdad? ¿Cómo podemos asegurarnos de que esta migración sea exitosa y de que podamos aprovechar todos estos beneficios al final? Comenzamos con los desafíos, ¿verdad? El tamaño mismo de sus productos, la alta sofisticación de los mismos, dificultaba realmente asegurarnos de que todo encajaría perfectamente. La complejidad local era el elemento clave, ¿verdad? Se trataba realmente de tratar de averiguar cómo cada una de estas piezas altamente sofisticadas se uniría como una sola plataforma. La solución fue la biblioteca de dominio. Madurar y lanzar una llave inglesa que era el sistema de design de SurveyMonkey fue una buena estrategia para ayudar a los equipos de características a ser más productivos y crear una apariencia y sensación cohesivas en la aplicación. Pero eso fue solo el comienzo. Simplificar el código de las características solo era posible si parte de la lógica de negocio y presentación en las propias características se compartían. Cuando se usaban los mismos conceptos en diferentes lugares, el código específico del dominio se encargaría de esa sección. El concepto está inspirado en el diseño orientado al dominio y ayudó a dar forma a una biblioteca que podría concentrar todo lo relacionado con uno de los

Bien, suficiente charla, veamos algo de código. Este es uno de los componentes más pequeños, es muy pequeño pero puede mostrarte el patrón. Es una de las cosas clave que tuvimos que admitir aquí y una de las razones por las que algunos de estos componentes eran muy específicos del dominio fue la visualización personalizada, como la capacidad de tematizarla de manera diferente en tiempo de ejecución. Logramos eso al tener este archivo separado junto a cada componente que le daba un estilo específico pero que también cambiaba la forma en que funcionaba el estilo en función del tema que era inyectado por el usuario final. Este es un componente ligeramente diferente pero sí, todavía muy básico. Es diferente de la versión del sistema de diseño del mismo componente debido a la capacidad del usuario final de tematizarlo. Esto es el resto. Es una entrada básica y también una de las primeras iteraciones. Los componentes visuales son de nivel 3 y esto es de nivel 1. Este es un ejemplo de una visualización. Las visualizaciones son componentes no visuales a pesar de su nombre. Están diseñadas para ser una de las cosas más fáciles de escribir porque tienes muchas de ellas. Su estructura está diseñada para mapear realmente el uso al actual

Entonces, uno de los aspectos más importantes de la estrategia fue asegurarse de que el código que se iba a escribir muchas veces fuera extremadamente fácil de escribir. Para ello, creamos un proveedor de capacidades. Nos aseguramos de que el usuario final no tuviera que pasar mucho tiempo preparando los tipos y configurando parámetros y cosas así. Para eso creamos un montón de ayudantes, como un montón de ayudantes que permitían a alguien simplemente usar esta fábrica aquí con una lista de visualizaciones y luego TypeScript inferiría los tipos para el proveedor de capacidades externas basado en las visualizaciones seleccionadas. Ahora veamos un uso típico aquí. Así es como lo usarías en el código de la aplicación. Obtendrías el proveedor de capacidades en algún lugar de tu código y dentro de él, entre todos tus otros componentes visuales, tendrías un único controlador de pregunta. El controlador de pregunta única sería reemplazado por la visualización apropiada dependiendo de cómo se configurara la pregunta en tiempo de ejecución. Por ejemplo, en este caso, tienes una caja de texto única que se renderizará como una caja de texto única y si cambias a una caja de comentarios, cambiará todo lo que se pueda cambiar en función de los datos que están dentro del tipo de pregunta. El propio tipo de pregunta está en el nivel dos y determina qué se puede cambiar en cada una de estas cosas. La idea aquí es que este es un ejemplo de una arquitectura evolutiva, ese es el concepto principal de esta solución, ¿qué es una arquitectura evolutiva? Es una arquitectura que puede soportar cambios y conciliar esos cambios sin perder cohesión. Es el antídoto para tener que hacerlo de nuevo en 10 años. ¿Verdad? Esta migración aún está en curso, pero podemos ver algunos resultados muy importantes del enfoque. El principal puede ser la respuesta de los equipos de ingeniería. Recibimos muchos comentarios positivos y algunos de los ingenieros realmente se involucraron en la oportunidad de entender lo que estaba sucediendo allí. Entonces, una de las cosas que realmente intentamos impulsar fue crear esta propiedad colectiva de la arquitectura, asegurarnos de que todos pudieran contribuir a ella y plantear sus problemas para que pudiéramos acomodarlos. Es muy importante tener esa flexibilidad, de lo contrario, terminas resolviendo problemas pero no los problemas correctos. Bueno, ahora lo único que falta son los bonos de mono. ¿Cómo llamas a un grupo de monos muy jóvenes que son hermanos y te gritan una advertencia todo el tiempo? ¡Monjes! Bueno, gracias a todos. Espero que les haya gustado la presentación. Si quieren saber más, únanse a mí para la sesión de preguntas y respuestas. Parece que en cuanto a la pregunta de cuánto tiempo tiene el código más antiguo que tienen que mantener en su día a día, parece que el ganador es de cinco años con un 38 por ciento, y el siguiente, el segundo lugar, es de menos de tres años. Así que entre tres y cinco años, supongo. ¿Qué opinan al respecto? Sí, eso es bastante interesante porque, como cinco años en JavaScript, es mucho tiempo. Significa que probablemente temes tener que hacer ciertas cosas porque probablemente serán más difíciles en ciertas partes de tu código que en otras partes de tu código.

Y te estás perdiendo oportunidades. La gente te pide que hagas cosas y tú te quedas pensando. Eso es difícil. Y es un gran desafío, ¿verdad? Cuando tienes este código en el que dependes para generar valor para el negocio, no quieres pasar todo el tiempo reconstruyéndolo. Pero en algún momento te verás obligado a hacerlo porque hay otras cosas que quieres hacer que dependen de que ese código sea más moderno. Sí, eso es seguro. Te lo puedo decir porque en el pasado solía trabajar en una startup y en realidad fuimos uno de los primeros en adoptar React, diría que hace casi ocho años. Y comenzamos con Create Class. Usamos mixins y todo, ¿verdad? Como el azúcar, y de repente tuvimos que pasar a usar clases, y también teníamos pruebas unitarias, y todo era un desastre. También queríamos pasar a TypeScript. Y fue, ¿cómo puedes hacer todo al mismo tiempo? Y fue realmente, realmente difícil. O tenías que reescribir todo o, no sé, hacer algo como modos de código y todo eso. Y solo tenía tres años. Así que cinco años todavía parece mucho también. Pero veo que incluso 10 años, se vuelve cada vez más difícil de mantener después de un tiempo, especialmente para JavaScript, como tú

Exactamente. Hablando de preguntas, tenemos bastantes preguntas. Comenzaré con una de Popling. ¿Se puede considerar el desplazamiento como una primera entrada? ¿Considerarse qué? ¿Se puede considerar el desplazamiento como una primera entrada? Eres el experto. No entiendo exactamente la pregunta, pero tal vez, Popling, si puedes agregar más información, lo abordaremos.

Tomemos otra de Tom HD. ¿Cómo llegaron a los tres niveles de arquitectura? Sí, está bien. Podemos abordar el desplazamiento después. Creo que lo entendí, pero los tres niveles, comenzamos con lo más simple posible que pudiera funcionar. Construyamos los componentes visuales y las personas los usarían como quisieran. Esa es la primera idea. Luego comenzamos a pensar en las restricciones que siempre deberían cumplirse. Si eso sucede, algunas cosas podremos hacerlas y otras no. Y lo que no podrías hacer si todos pudieran consumir solo componentes visuales en todas partes. No podrías estandarizar la forma en que abordan la recopilación, obtención de datos del backend de GraphQL y la estructura de estos datos. ¿Cómo harían las validaciones, cómo harían las transformaciones, todas estas cosas? Hay una oportunidad perdida allí. La pregunta siempre debe ser: ¿De acuerdo, qué estás dispuesto a sacrificar a cambio de la capacidad de centralizar estas cosas? Ahora vas a construir un poco más de complejidad, pero vas a obtener algo. Así que comenzamos a tener esas conversaciones. De acuerdo, ustedes dijeron que querían esto, que querían que las características de estas aplicaciones se expandieran fácilmente. ¿Cómo podemos reducir el costo para estos desarrolladores? Podríamos eliminar algo de ellos, pero ahora les damos la capacidad de hacer algo realmente rápido. Esto será como reducir su complejidad y darles un poco menos de opciones de personalización. Y en algún momento comenzamos a tener problemas. Como, de acuerdo, ahora en esta situación aquí, a medida que comenzamos a crear un inventario de todas las cosas que debían hacerse. En algún punto de la aplicación, como, de acuerdo, estas personas realmente necesitan personalizar esta parte aquí. Así que ahora les damos un mecanismo. Pero si les damos un mecanismo, estamos agregando complejidad nuevamente. Y ese intercambio, de acuerdo. Y la conversación continúa. Y al final, descubrimos que esta complejidad que se acumulaba dentro de la biblioteca de dominio

De acuerdo. Muy bien. Sigamos adelante, porque tenemos muchas preguntas. Permíteme tomar la otra. ¿También puedes hacer lo mismo con el desplazamiento, además de lo que dijiste? Permíteme leer de nuevo. Creo que está preguntando si el desplazamiento es una entrada que va a la infraestructura. Eso depende, por supuesto. El límite real de esto es el dominio vertical, el contexto acotado al que pertenece. Entonces, si te desplazas dentro de un componente, esa es la responsabilidad de la biblioteca proporcionar como un organismo, y esta cosa es un poco opaca para el exterior. Este componente debe encargarse del desplazamiento en sí. Pero si el desplazamiento es responsabilidad de algo que incluye eso, entonces la aplicación debe hacerlo y la comunicación entre la aplicación y la biblioteca debe tener algún significado que sea realmente representativo de lo que eso significa. Si es algo como, oh, ahora estás en vista, muéstrate. Ese es un mensaje que quieres enviar a la biblioteca en lugar de, oh, el usuario se desplazó 10 píxeles. Esa es la clave. Tiene sentido. Urbon está preguntando, Jason, ¿tienes un repositorio Git con un ejemplo simple y jugable de arquitectura? No, en realidad no. Probablemente debería hacer eso. Soy un mal usuario de repositorios Git públicos. Debería hacer eso con más frecuencia. Creo que el código público más antiguo que escribí tiene como dos años o algo así. En años de JavaScript, eso es una eternidad.

Genial. Sí, eso es realmente una buena respuesta, para ser honesto. La última pregunta es de Arek. Tenemos tiempo para una pregunta más. Entonces, ¿cómo se evita que las aplicaciones enterprise se conviertan en legado después de dos años? ¿Tienes algún consejo o truco para hacerlo? ¿Cómo evitar ser legado después de dos años? Sí, no hay una solución mágica, ¿verdad? Y es algo que es realmente importante que entendamos, que como tecnólogos consideramos algo legado una vez que deja de ser un juguete brillante, ¿verdad? Miramos las cosas y decimos: no puedo creer que todavía estés usando componentes de clase, ¿verdad? Eso no es realmente cierto. El código que está ahí, entregando un gran valor a los usuarios, es un gran código, ¿verdad? El enfoque está en cuando estás perdiendo oportunidades para brindar una gran experiencia a los usuarios, entonces comienzas a pensar: ¿puedo justificar reconstruir esto o debemos invertir este tiempo en construir algo nuevo, ¿verdad? Dependiendo de la respuesta, es posible que desees agregar cada pocos meses o incluso todos los días una pequeña pieza moderna a tu código. Sí, solo para mejorar todo, ¿verdad? Solo para mejorar la experiencia del usuario y luego publicarlo para el usuario, ¿verdad? porque el usuario final importa, sí, desafortunadamente se acabó el tiempo, pero Jason estará disponible en Spatial Chat, ¿verdad? Así que la gente puede discutir más contigo allí, ¿verdad? ¿Es eso correcto? ¿Vas a estar allí o sí, voy a ser increíble, sí increíble, muchas gracias, muchas gracias y el tiempo pasó tan rápido, disculpa por eso, pero fue una charla genial, muchas gracias por tomarte el tiempo y disfruta el resto del día y no te olvides de Spatial Chat con Jason, gracias Jason, muy bien gracias a todos, adiós