El camino a través del legado: Delicado equilibrio entre tolerancia y fobia

Rate this content
Bookmark
Slides

Como líder de equipo de front-end, me enfrenté al desafío de transicionar múltiples proyectos heredados, lo cual sucedió rápidamente y fue un proceso doloroso. Uno de los principales problemas con los que me encontré fue lidiar con un proyecto heredado que no tenía documentación. Tuve que descubrir cómo estabilizarlo, ponerlo en orden y reducir el costo de su mantenimiento y desarrollo.

8 min
06 Jun, 2023

Video Summary and Transcription

El legado puede referirse a la arquitectura antigua o al código antiguo, y es importante reconocer y abordar los problemas heredados. El código heredado puede estar desorganizado y desactualizado, lo que dificulta su actualización y ampliación. El objetivo es dejar la base de código en mejor estado que antes, priorizando el código que es fácilmente modificable por otros.

Available in English

1. Introducción a Legacy

Short description:

Hoy hablaremos sobre el legado. El legado puede ser alguna arquitectura antigua o código antiguo. Los juegos de legado se construyen sobre iteraciones anteriores para crear una experiencia de juego única. Reconocer el problema a tiempo es esencial para combatir el legado. La reescritura puede ser justificable en ciertas circunstancias. La documentación es importante pero a menudo es descuidada por los desarrolladores.

Hola, mi nombre es Max. Hoy hablaremos sobre el legado. Primero, unas palabras sobre nuestros proyectos. En Teotihu, Kazajistán, Altel Digital, desarrollamos cuatro aplicaciones móviles principales, más de 10 aplicaciones web y más de 150 microservicios.

Hablemos de los buenos y viejos problemas esenciales. ¿Qué es el legado? Puede ser alguna arquitectura antigua, tal vez casos de juegos de mesa. Todos dejaron su camino de legado en este mundo. Funciona en ambos sentidos. Pegatinas en tu mapa de juego de mesa o la dependencia cruzada de tu paquete en el proyecto de React. Bueno, tanto los juegos de legado como los códigos de legado comparten la misma característica común de pasar algo del pasado. Los juegos de legado se construyen sobre iteraciones anteriores para crear una experiencia de juego única y personalizada.

Entonces, ¿qué es el código de legado de todos modos? Podrías caer en la trampa de pensar que es solo un código antiguo. Sí, puede ser antiguo. Pero el código antiguo no se considera necesariamente legado solo porque es antiguo. Con este enfoque, tu propio código que escribiste ayer ya es legado. Las siguientes características pueden resultarte familiares. La respuesta de que escribimos código que probablemente termine como legado está fuera del proceso de codificación e implementación real. Si estás haciendo tu propio proyecto pequeño o startup, es más probable que escribas rápido y lo revises más tarde. Hoy en día, si no has tomado esta ruta como un equipo pequeño o un proyecto de un solo hombre, es muy probable que no tengas un negocio. La clave es reconocer el problema a tiempo para mover las formas prácticas de combatir el problema. Desafortunadamente, no existe un instrumento en el desarrollo de software como MagiKwan o la Espada de los Mil Verdades para hacer todo lo que queremos de manera perfecta. Pero al igual que las armas y las barras de maná son herramientas para el éxito en la experiencia de juego, el compromiso estándar es esencial para utilizar la tecnología de manera efectiva y responsable.

Como desarrolladores, encontramos la idea de reescribir porque es más fácil. Al menos, eso es lo que pensamos. Es más fácil juzgar el código escrito antes que nosotros y pensar que tenemos una mejor solución, a menudo ignorando la lógica empresarial que el código antiguo sirve y los casos especiales que intentaba resolver. Si bien tiendo a creer que la reescritura a menudo no es necesaria, puede haber ciertas circunstancias en las que sea justificable. Por ejemplo, si una sección particular de un proyecto ha alcanzado su límite y se requieren hacks o soluciones complicadas para su expansión posterior, o si ciertos componentes ya no se utilizan y se pueden aislar, comenzar de nuevo puede ser la mejor opción. La documentación es una de esas cosas en las que todos los desarrolladores están de acuerdo, pero pocos lo hacen. Al menos de manera práctica y eficiente.

2. Desafíos del Código Heredado

Short description:

Puedes escribir una cantidad interminable de código desorganizado y obsoleto, lo que dificulta enormemente su actualización. Un trozo de código puede funcionar, pero no es útil si no se puede extender. Recuerda lo que te dije antes. El código que escribas hoy será código antiguo mañana. Nuestra tarea es dejar la base de código en un estado un poco mejor que como la encontramos. En lugar de seguir las mejores prácticas, es preferible priorizar la creación de código que sea fácilmente modificable por otros.

Puedes escribir una cantidad interminable de código desorganizado y obsoleto, lo que dificulta enormemente su actualización. Es mucho más fácil escribir mucha documentación sin sentido. Algunos dicen que la base de código puede ser documentación en sí misma, pero tener un pequeño número de enlaces y anclas en tu repositorio puede ser algo bueno. Es casi un arte en sí mismo.

Un trozo de código puede funcionar, pero no es útil si no se puede extender. Claro, puede funcionar como se espera y aún generar ganancias para la empresa, pero un día puede romper todo el flujo de trabajo del negocio. Podemos minimizar el problema manteniendo las cosas aisladas para que no afecten al resto del código. Esta puede ser una solución permanente.

Por lo general, cuando escribes cosas nuevas, dependerán de algún sistema heredado, dependiendo del tamaño, cuanto más grande sea la base de código, más desafiante será arreglar eso. Por lo tanto, optimizar tu código para el cambio y hacer que sea más fácil de eliminar, irónicamente, hace que sea más fácil de extender con el tiempo y no producirás código heredado hoy. Recuerda lo que te dije antes. El código que escribas hoy será código antiguo mañana. ¿Tu intención es ser el más inteligente o es ayudar a todos los futuros desarrolladores que probablemente vendrán mucho después de que te hayas ido? Nuestra tarea es dejar la base de código en un estado un poco mejor que como la encontramos. En lugar de seguir las mejores prácticas, es preferible priorizar la creación de código que sea fácilmente modificable por otros. El objetivo aquí es hacer cambios incrementales en el sistema heredado. Cuando la opción se detiene, es cuando el código comienza a ser heredado. El código que cambia es lo único constante. Una decisión obvia es escribir pruebas. Cada vez que visitas una determinada sección, dependiendo del caso, puedes agregar pruebas de unidad o de comportamiento y lograr gradualmente una cobertura completa. Luego comienzas a mover las cosas más fácilmente. La única desventaja es que nuestras bases de código heredadas ni siquiera tienen pruebas o infraestructura de pruebas implementada. Independientemente de eso, el esfuerzo inicial y las dificultades involucradas, esta herramienta eventualmente demostrará su valía en el futuro. Ok, esto puede parecer extraño, pero la prueba general de que no tienes y no generas código heredado hoy, al menos tanto, es que cualquier persona de tu equipo puede ir y hacer cambios en todo el código base. Y los recién llegados tienen una forma de descubrir cómo trabajar con él sin necesidad de aclaraciones. Esto no significa que no haya lugares en la base de código donde las cosas no estén desordenadas, pero al menos hay una forma de navegar a través de ellas. Entonces, esto es lo que siempre intento hacer. Cuando tu base de código no depende de una sola persona, eso es una señal saludable. La capacidad de manejar y trabajar con el sistema heredado se considera un signo de experiencia dentro de los equipos. Es importante tener en cuenta que ninguno de los procesos mencionados anteriormente se puede lograr de la noche a la mañana. El proceso incremental es clave. En resumen, hemos aprendido que el código heredado es código que no se puede extender, pero es posible coexistir con él y mejorarlo gradualmente a través de actualizaciones bien documentadas y el enfoque continuo en la refactorización. Como ingenieros, nuestro objetivo principal es resolver problemas a través del código, pero es esencial no apegarse demasiado a ninguna base de código. Eventualmente, todo el código se volverá obsoleto, por lo que es crucial seguir buscando nuevos y interesantes problemas para resolver. Aquí lo tienes. Gracias por ver. Encantado de verte en el React Summit 2023.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
React Advanced Conference 2022React Advanced Conference 2022
29 min
Understanding React’s Fiber Architecture
Top Content
We've heard a lot about React's Fiber Architecture, but it feels like few of us understand it in depth (or have the time to). In this talk, Tejas will go over his best attempt at understanding Fiber (reviewed by other experts), and present it in an 'explain-like-I'm-five years old' way.
React Finland 2021React Finland 2021
36 min
The Eternal Sunshine of the Zero Build Pipeline
For many years, we have migrated all our devtools to Node.js for the sake of simplicity: a common language (JS/TS), a large ecosystem (NPM), and a powerful engine. In the meantime, we moved a lot of computation tasks to the client-side thanks to PWA and JavaScript Hegemony.
So we made Webapps for years, developing with awesome reactive frameworks and bundling a lot of dependencies. We progressively moved from our simplicity to complex apps toolchains. We've become the new Java-like ecosystem. It sucks.
It's 2021, we've got a lot of new technologies to sustain our Users eXperience. It's time to have a break and rethink our tools rather than going faster and faster in the same direction. It's time to redesign the Developer eXperience. It's time for a bundle-free dev environment. It's time to embrace a new frontend building philosophy, still with our lovely JavaScript.
Introducing Snowpack, Vite, Astro, and other Bare Modules tools concepts!
React Summit 2022React Summit 2022
17 min
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
Top Content
There are many ways of authoring components in React, and doing it right might not be that easy, especially when components get more complex. In this talk, you will learn how to build future-proof React components. We will cover two different approaches to building components - Composition and Configuration, to build the same component using both approaches and explore their advantages and disadvantages.
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Remix Architecture Patterns
Top Content
Remix provides amazing flexibility and can be deployed anywhere where JavaScript is running. But how does Remix fit into the bigger application landscape of an organization? Remix provides great utility, but how to best take advantage of it? What things should be handled inside of Remix, and what things are better off done elsewhere? Should we use the express adapter to add a WebSocket server or should that be a standalone microservice? How will enterprise organizations integrate Remix into their current stacks? Let’s talk architecture patterns! In this talk, I want to share my thoughts about how to best integrate Remix into a greater (enterprise) stack.

Workshops on related topic

DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.