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

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.

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.