¡Bienvenido!
A todos nos da miedo el código legacy. Un proyecto legacy que lleva años sin modificarse, sin actualizarse, el famoso «mientras funcione, no lo tocamos». Aquel que impone, que llaman «terreno pantanoso». Y, sobre todo, que no tiene tests (terrorífico, ¿eh?).
Cuando hay que modificar el comportamiento de un código así o arreglar un bug, los voluntarios suelen brillar por su ausencia. Nadie quiere entrar en ese marrón.
Pero alguien tiene que hacerlo, ¿no? Si te ha tocado, voy a intentar hacerte la vida un poco más fácil.
Levantando el proyecto
Lo primero es lo primero: Lanzar el proyecto en nuestro entorno local. A ver ese README.md… Si es que existe. Con suerte no solo existe, sino que tiene información útil.
El proyecto tiene que funcionar. Si está dockerizado, probablemente estés de suerte y solo tengas que adaptar la configuración que trae el Dockerfile o el docker-compose.yml a una versión actual.
Si no está dockerizado, vete poniendo guantes. Voy a hablar en términos de Ruby pues es con lo que más familiarizado estoy, pero los conceptos deberían poder aplicarse a cualquier lenguaje.
Preparando el entorno
Muchos lenguajes o frameworks incluyen el lenguaje (y, muy importante, versión del mismo) que requieren en algún archivo. Éste puede estar en la información del paquete de Node.js, en el Gemfile… dependerá del lenguaje (y de la suerte que tengas).
Si no hay suerte, entonces un buen lugar al que ir es a la versión del framework que utilice, o de alguna librería. Por ejemplo, si el proyecto requiere Rails 3.2, puedes ir a ver con qué versiones de Ruby es compatible Rails 3.2 e instalarla, y haz lo mismo con otras dependencias (como bases de datos, redis, etc).
Puede que necesites un rato, pero tras ello deberías conseguir, al menos, que el proyecto arranque.
La faena: hacer tests
Felicidades, has conseguido arrancar el proyecto. Ahora toca tratar de hacer tests de todo lo que podamos. Ve poco a poco, busca una clase relativamente simple. Algo por donde empezar.
La idea aquí es coger algo que sea muy simple de entender y empezar a hacer tests que cubran al menos los casos más básicos de lo que ya está implementado. Si, por otro lado, te toca arreglar un bug de algo más grande, la inversión de tiempo en hacer tests de la/s clase/s que necesites modificar merecerá la pena. Ganarás un montón en estabilidad y en conocimientos.
Por supuesto será muy difícil tener en cuenta dependencias, lógica de negocio y factores que no sean tan visibles (como workers en segundo plano o una comunicación por eventos). Esto se puede tratar de paliar si cuentas con ayuda de alguien que sepa mucho de la lógica de negocio, además de tratando de hacer algún test end2end una vez ya tengas algo de experiencia con el código.
Próximos pasos
Ahora nos quedan dos posibles caminos por recorrer: Por un lado actualizar librerías y lenguaje si tenemos intención de modernizar el proyecto. Por el otro, solucionar los bugs que encontremos y dejarlo como está (spoiler: probablemente sea mejor rehacerlo, pero a management igual no le hace tanta gracia).
Para el primer camino, deberías poder tener una gran cantidad del código cubierto por los tests. Nunca se sabe cuándo una actualización mayor de una librería te va a fastidiar el asunto. Otra opción es crear un nuevo proyecto con tecnologías modernizadas e ir migrando poco a poco el código.
Para el otro camino, tu mejor baza vuelven a ser los tests. Haz todos los que puedas, verifica que pasan exitosamente y, ahora, haz tests nuevos que deberían estar fallando hasta que arregles el bug. Después, todos los test ya deberían pasar.
Wrap-up
Enhorabuena, has navegado con éxito (o, al menos, aprendido algo al respecto) por un proyecto Legacy. Es normal que den respeto, pero es algo a lo que debemos saber enfrentarnos, ya que es muy probable que algún día seamos nosotros a quienes les toque ponerse los guantes y meternos a ello.
¡Un saludo!
¿Quieres seguir aprendiendo sobre legacy code? Te dejamos un artículo que pensamos que te gustará aquí.
