El código heredado, o término más conocido por su forma inglesa, leagacy code. Son aquellos proyectos que te llegan de alguna manera u otra. Y empiezas a formar parte de ese legado de personas, de esa estirpe de desarrolladores que han creado y hecho crecer ese proyecto. Como si de un hijo se tratase. Al que cuidas, quieres , mimas con cariño y te sientes orgulloso.
Cuando recibes el código
Encontrarte con un proyecto empezado, o que ha estado cancelado durante mucho tiempo. Recuperar ese prototipo de tu idea feliz. Esto es algo que tanto en el mundo personal y profesional un desarrollador se encuentra. Y siempre se acaba pensando lo mismo. Desde él «esto no hay por donde cogerlo» o «es mejor desecharlo y empezarlo de nuevo» acabando por el «¿Quien coj*nes habrá hecho este desastre?» sin para a pensar que quizá haya sido nuestro yo del pasado.
Esto es el pan nuestro de cada día en la industria. Tanto si trabajas por cuenta ajena, como por cuenta propia. Lo más normal es que te toque continuar un proyecto ya en funcionamiento.
Con algo de suerte, empiezas como un mantenimiento. Donde te vas familiarizando con todo y con gente que ya está en el proyecto y son tus mentores. Para ti son la fuente de sabiduría. Aprendes de primera tinta sobre la toma de las decisiones. Ves técnicas que puedes replicar y te sirven de apoyo en tus futuros desarrollo. En estos casos, la homogeneidad del código es importante.
Por lo contrario, si te encuentra la mala suerte. Habrás cogido con toda tu ilusión un proyecto que no solamente deberás darle un mantenimiento. Si no también, tendrás que ampliar sus funcionalidades. Donde para colmo, no estás muy ducho con esa tecnología y eres el único valiente que acepta ese proyecto. Sin la posibilidad de contactar con la gente que un día hizo el desarrollo. Cuando te das cuenta del error que has cometido. Ya es demasiado tarde y solo te queda ir hacía delante con todo.
En resumen, en ambos casos te ves en la tesitura de ser el nuevo mantenedor del proyecto. Esto te hace mejorar en la habilidad de bucear en el código y descifrar funcionalidades de él. Esto te prepara para poder descifrar cualquier cosa como si de un libro abierto se tratase.
Cuando tu dejas el código
Y como habréis imaginado. No hay nada que me guste más que empezar un nuevo proyecto. Donde todo esta por hacer y puedes elegir lo que quieras. Tiene un amplio abanico de posibilidades. Solo tus conocimientos e imaginación son las limitaciones. Puedes hacer lo que quieras. Pero esto no siempre es posible. Y, menos en los primeros pasos del mundo laboral.
En todos estos años, solamente he empezado y plantado la semilla de 2 proyectos a nivel profesional. Aunque, realmente, solo diría que uno. Dado que en uno de ellos entré cuando había algo empezado y la solución a implementar venía decidida por otro grupo de personas. En el que poca voz y voto tenía. Las cuestiones más importantes ya se habían resuelto. O eso parecía.
De los proyectos nuevos, aprendí a nivel técnico de dos formas muy distintas. Por un lado, con la experimentación de implementar nuevas tecnologías. Donde te zambulles en un mar de documentación. A base con prueba y error. Confiando que lo estás haciendo de la mejor manera y que va a ser la mejor solución. Pero llega el momento, llega el otro lado de la moneda, la otra forma de aprender. Tan solo un tiempo después, cuando ya te has familiarizado con esa nueva tecnología y echas la vista atrás. Momento en el que antes creías que habías hecho el nuevo David de Miguel Ángel. Pero te encuentras con una serie de líneas de código que no querrías que nadie más viese. Y piensas en rehacerlo todo de nuevo. En esos momento te das cuenta, que no todo lo que en su momento creías que era lo mejor. Pero no lo era.
Esto te ayuda a ver los proyectos heredados y el código de otra manera. Muchas veces es por prisas, por llegar a cumplir tiempos, otras por simple desconocimiento. Aunque al final sea lo mismo, deuda técnica que en algún momento se tiene que pagar. Y cuando antes se pague mejor, si no, lo intereses van subiendo.
¿Como cambiarlo sin morir en el intento?
Que hacer cuando caemos en un proyecto heredado y no tiene documentación, no conocemos a nadie que haya estado trabajando con él y no querer morir en el intento de bucear en miles de líneas de código y/o de una tecnología que no conoces. Una buena manera de ir reduciendo esta deuda técnica es mediante la refactorización y test automáticos. Con ayuda de metodologías de desarrollo como TDD, BDD, test End-to-End o test de ingración. De los cuales ya hablaremos en otro momento.
Y esto mismo se debe y tiene que aplicar a los nuevos proyectos que se empiezan o las nuevas funcionalidades. Nuestro yo del futuro nos lo agradecerá. Al igual que la gente que venga detrás. Y con todo esto también lograremos cumplir un poco más del Código Limpio (Clean Code), y seguir la regla del Boy Scout. Dejar las cosas igual o mejor que nos las encontramos.