¿Qué hacer cuando el código apesta?
¿Te ha pasado alguna vez que has empezado a trabajar en una codebase que ya existe y tiene algo de tiempo, no hay a quién preguntarle y no se entiende nada?
Imagina lo siguiente: Entras en una empresa nueva o cambias de proyecto y te toca trabajar con código ya existente y que está funcionando en producción. Pero hay una pega, eres la única persona que va a estar trabajando en ese código y la última que lo tocó lleva meses fuera de la empresa. Sea como sea, no tienes a quién preguntarle por el código.
La aplicación funciona, con sus más y sus menos, pero es imposible de entender. No hay tests ni documentación, las reglas de linting no se respetan y los principios SOLID brillan por su ausencia.
Para colmo, las versiones de la mayoría de librerías utilizadas están desfasadas. Ejecutas el proyecto y te saltan warning y errores, y piensas WTF? (cómo la aplicación seguía funcionando nadie se ha preocupado por esos mensajes de error, mejor no tocar lo que funciona).
No estás solo
Esto es algo bastante corriente en realidad. Sobretodo sucede en empresas pequeñas, proyectos legacy (código muy antiguo en tecnologías desfasadas que nadie quiere tocar) y proyectos subcontratados.
Aunque no haya nadie concreto que pueda ayudarte en la empresa, pregunta a los demás e intenta tirar del hilo para conseguir toda la información posible. Por ejemplo, puede que ningún desarrollador esté manteniendo una aplicación pero los técnicos de operaciones tienen que poder ser capaces de desplegarla, reiniciarla, etc.
¿Cómo empezar a darle sentido a todo?
Lo primero que debes hacer es conseguir que la aplicación arranque en modo desarrollo. Si hay un README, debería de explicar cómo hacerlo. Si no tienes esa suerte tendrás que echar un ojo a las dependencias, los archivos de configuración y la estructura de archivos del proyecto.
Si el proyecto está en una tecnología que desconoces, busca la documentación y revísala. Debes asegurarte de buscar documentación sobre la versión específica de la tecnología que sea que estés usando si está desactualizada, ya que puede haber cambios no compatibles que hagan inútil la documentación de las versiones nuevas.
No intentes arreglarlo todo de golpe
Empezar a refactorizar todo el código puede ser peligroso, especialmente si no hay tests. Igualmente empezar a crear tests para todo el código existente puede ser poco práctico y consumir muchos recursos.
En lugar de intentar refactorizar todo de principio a fin, intenta arreglar aquello que toques.
Por ejemplo, si te ves obligado a trabajar en el routing para añadir una ruta nueva, puedes intentar mejorar el código referente al routing.
Si tienes que modificar un componente que no está testeado puedes empezar haciendo los tests para la funcionalidad que ya existe e intentar hacer Test Driven Development para esos cambios que quieres aplicar.
Testea antes de refactorizar
Una vez empieces a arreglar el código debes tener cuidado de no romper nada. Lo mejor que puedes hacer es crear tests que prueben la funcionalidad que ya existe.
Una vez tengas los tests funcionado tienes la tranquilidad de poder refactorizar asegurándote de que todo sigue funcionando después.
Recorriendo la historia
Mucho más importante que los archivos del proyecto en si mismos, es la historia que cuentan. Revisa en git los históricos de pull requests y commits.
Si las Pull Request (o Merge Request) están bien hechas, debería de haber una buena explicación de la característica que se introduce en cada una de ellas, e incluso una discusión al respecto.
El histórico de commits puede servirte para ir viendo como ha ido cambiando el código a lo largo del tiempo.