Los legados nunca mueren: Cómo manejar el código Heredado

Cuando aparece el término «código heredado», generalmente se dice o recibe con un tinte de desdén. Una búsqueda preliminar en Google de» memes de código heredado » muestra cientos y cientos de macros de imágenes de personas que se arrancan el pelo, se ven agotadas o muy decepcionadas.

Cuando empecé a trabajar como desarrollador de software hace 6 meses, no tenía idea de qué era el código heredado o qué implicaba trabajar con él.

Durante mi cuarto mes como desarrollador junior, me pidieron que agregara un modal de filtro de búsqueda a una aplicación creada por uno de mis compañeros de trabajo hace dos o tres años. Parecía bastante fácil; había pasado la mayor parte de los últimos cuatro meses trabajando en una aplicación increíblemente compleja para otro cliente que involucraba nuestra pila estándar: TypeScript/React/Redux/Redux-Saga. Ya había resuelto muchos problemas únicos y me sentí seguro de mi capacidad de codificación lo suficiente como para hacer un modal simple para pasar parámetros de consulta al backend.

Como habrás adivinado, no fue tan simple. ¿Pero por qué?

Qué es el código heredado y por qué puede ser difícil lidiar con

El código heredado es un código heredado de otro desarrollador o equipo que utiliza tecnologías más antiguas que ya no son compatibles o que han sido reemplazadas por una versión más reciente. Muchos programadores dicen que «el código se convierte en código heredado tan pronto como se escribe». La diferencia funcional entre el código «regular» y el código heredado podría ser simplemente que tiene convenciones diferentes en comparación con lo que está acostumbrado a trabajar.

En mi caso, la aplicación a la que me asignaron utilizó Flow en lugar de TypeScript, y no estaba tan mecanografiada como estaba acostumbrada. Esto me hizo un poco más difícil entender la estructura de los datos que se estaban obteniendo del backend. Ningún tipo significaba que me encontraba con TypeErrors en tiempo de ejecución con mucha más frecuencia, lo que puede ser difícil de depurar cuando escribes una característica grande. Además de esto, la aplicación usó una versión mucho más antigua de React que necesitaba reconciliarse con una versión compatible de la biblioteca de componentes que quería usar para compilar el modal.

Antes de entrar en el meollo de cómo manejar el código heredado con un sentido de equilibrio y racionalidad, quiero agregar una advertencia de que el código heredado no es del todo malo y trabajar en un proyecto heredado no tiene que ser terrible. Por el contrario, trabajar en código heredado me enseñó a ser flexible, paciente y, sobre todo, la experiencia me permitió resolver problemas con una nueva perspectiva en un contexto novedoso.

De hecho, me hizo un mejor desarrollador de lo que era antes de comenzar a trabajar a través del código base mencionado anteriormente, y espero que su proyecto heredado también pueda enseñarle algo.

Cómo lidiar con el código heredado a nivel técnico

Foto de Jeff Sheldon en Unsplash

Leer documentación y comentarios de código cuando sea posible

En un mundo perfecto, cada base de código tiene un LÉAME robusto que contiene explicaciones concisas de cómo funciona el proyecto, comentarios de código que explican la lógica exacta del autor original, y toda la aplicación tiene sentido. Sin embargo, rara vez es así. Muchos READMEs no se actualizan a medida que se desarrollan los proyectos, la gente se olvida de escribir comentarios, asume que su lógica es obvia para un nuevo desarrollador, o simplemente se queda sin tiempo para ocuparse de esas cosas.

Mira la base de código como un todo

Si estás perdido y no sabes por dónde empezar, hazte estas preguntas:

• ¿Cuál es el propósito de la aplicación?
• ¿Cómo fluyen los datos a través de la aplicación?
• ¿Cómo encaja tu función en la aplicación?

Cuando puedes tener una idea del panorama general, es más fácil descubrir la mejor manera de abordar el problema. Tal vez necesite crear un nuevo archivo y crear un nuevo componente. Tal vez necesite escribir una función de utilidad y probarla. Sea cual sea el caso, comprender el contexto más amplio de su problema es un buen primer paso para crear una solución.

Pruebe la aplicación manualmente y con pruebas unitarias siempre que sea posible

Romper una aplicación temporalmente mientras agrega una nueva función es inevitable, sin importar el nivel de desarrollador que tenga. Esto es normal y esperado, especialmente si es nuevo en el trabajo, trabaja en una base de código heredada con una pila desconocida o alguna combinación de los dos.

La mejor manera de evitar que estas roturas se conviertan en problemas a largo plazo es probar su aplicación a fondo con pruebas unitarias y pruebas manuales. Tener estas pruebas en marcha y saber exactamente qué tipo de cobertura obtiene de ellas le ahorrará a usted y a los futuros desarrolladores mucho tiempo. Además, las pruebas rigurosas hacen que la aplicación sea más escalable y también le dan un poco de dopamina cada vez que sus pruebas se ejecutan limpias.

Para pruebas unitarias, puede usar marcos de prueba como Jest o Jasmine.

Para las pruebas manuales, querrá desarrollar una matriz de pruebas y asegurarse de que el documento sea accesible para los futuros desarrolladores. Para la matriz, querrá definir un conjunto de acciones, el comportamiento esperado, el comportamiento real cuando la pruebe y cualquier otro detalle que sea importante, como por ejemplo:

En una publicación de blog futura, explicaré cómo implementar ambos tipos de pruebas de manera eficiente en su flujo de trabajo.

Pide ayuda

Suponiendo que tu proyecto haya sido escrito por un empleado actual o anterior en tu lugar de trabajo, es probable que otra persona sepa lo que está pasando en la aplicación, o al menos sepa lo suficiente para liberarte. Aprender a tragar tu orgullo y preguntar a otra persona es un paso incómodo para algunos, pero necesario para crecer como desarrollador, y tal vez tu compañero de trabajo pueda enseñarte algunos trucos nuevos.

Una buena manera de hacer un uso eficiente de su tiempo (y el de ellos) es formular preguntas informadas. Trate de volver a mirar el código base como un todo y averiguar las brechas en su comprensión. No solo les ayudará a tener una mejor idea de cuál es su problema, sino que muestra que tomó la iniciativa de tratar de resolver el problema por su cuenta primero.

Sepa cuándo reducir sus pérdidas

Si está pasando demasiado tiempo tratando de poner su pie en la puerta y no ha dado un paso serio hacia la implementación de la función después de probar los pasos anteriores, podría valer la pena refactorizar el código alrededor de su función. No te rindas con demasiada facilidad, pero también ten en cuenta cuáles son tus plazos de entrega y lo que tu gerente de proyecto espera de ti.

Dicho esto, hay inconvenientes en hacerlo de esa manera:

• Reescribir el código puede introducir errores, aunque esto puede eludirse con buenas pruebas unitarias.
• Reescribir el código puede eliminar la funcionalidad oculta, aunque esto también se puede evitar con buenas pruebas unitarias.
• Si estás presionado por el tiempo, escribir código fuera de tu función además de tu función puede llevar más tiempo que simplemente construir alrededor de ella.

En general, usa tu mejor criterio. Hay pros y contras para cualquiera de las opciones, y todo depende de sus circunstancias individuales y el presupuesto del proyecto.

Cómo lidiar con el código heredado a nivel psicológico

Foto de Simon Migaj en Unsplash

Ahora que hemos cubierto los aspectos técnicos de lidiar con el código heredado, hablemos de cómo lidiar con él usando nuestras habilidades blandas. Después de todo, los desarrolladores son personas, no solo robots de codificación, y lidiar con problemas desafiantes en proyectos que requieren creatividad y autoría puede ser emocionalmente agotador, no solo para usted, sino también para sus compañeros de trabajo.

Sé humilde y amable

Esto es algo que admitiré tímidamente que necesito practicar más. Cuando me asignaron por primera vez el proyecto modal de filtro, fui bastante vocal sobre lo janky y poco atractivo que debía lidiar el código mientras el autor original del código estaba sentado a 15 pies de distancia de mí. Pretendía que mis comentarios fueran una broma, pero en retrospectiva reconozco que estaba siendo arrogante e hiriente, y que debería haber sido más empática.

Hay muchos factores que pueden llevar a que el código heredado se vea «apagado», que debe tener en cuenta antes de comenzar a criticar al autor o asumir lo peor de ellos (¡Esto está vagamente vinculado al error de atribución fundamental!).

El autor original puede haber tenido sus razones para escribir código de la manera en que lo hizo.

Las limitaciones de tiempo y de tecnología pueden hacer que una persona escriba código que funcione, pero no necesariamente tenga la mejor convención. Si te imaginas en una situación con poco tiempo, herramientas obsoletas y una lista de tareas pendientes de una milla de largo, ¡probablemente tampoco escribirías el mejor código!

Las convenciones cambian.

En los proyectos Olio Apps más antiguos, la convención para el código es usar comillas simples para declarar cadenas, y dos espacios equivalían a una pestaña. Teníamos múltiples componentes de React pequeños anidados dentro de un solo archivo. En nuestra convención actual, usamos comillas dobles y cuatro espacios, y cada componente de React, sin importar cuán pequeño sea, vive en su propio archivo .tsx en el directorio component. Y en varios años, estoy seguro de que eso también cambiará.

Todo el código eventualmente se convierte en legado

Esto se vincula con el punto anterior: su código eventualmente será legado. A medida que subas en la escala de antigüedad, se contratarán nuevos desarrolladores y tendrán que mantener tu código antiguo. Es posible que escriba código limpio, impecable y SECO, pero una vez que cambien las convenciones o las tendencias, los nuevos desarrolladores pueden ver su código de la misma manera que usted ve el código heredado de otros.

Enorgullécete de los pequeños éxitos

No es fácil trabajar fuera de tus convenciones habituales; hay una razón para el gran tesoro de memes y chistes sobre cómo lidiar con el código heredado. Si alguna vez has aprendido un idioma fuera de tu lengua materna, sabes lo que se siente olvidar una palabra o término en tu segunda lengua, pero recordarlo en tu lengua materna y no ser capaz de traducir a través de la brecha. Lo mismo ocurre con el cambio entre las convenciones modernas y heredadas. A veces solo toma un minuto para recuperar su orientación.

Al poder navegar con éxito por el código heredado, está demostrando su capacidad de adaptación, que es una habilidad importante que lo beneficia en su trabajo actual y en todos sus trabajos futuros, ya sea que esos trabajos estén en el campo de la tecnología o no. El código heredado es el patio de recreo perfecto para practicar esta habilidad.

En conclusión:

Use este tiempo para reforzar su propia escritura de código

Ahora que ha tenido la experiencia de trabajar en una base de código heredada, debería salir de ella con una mejor idea de lo que le gusta y no le gusta en términos de herramientas y convenciones. Estas son cosas con las que puede continuar en proyectos futuros y mejorar la revisión del código de otros, ofrecer críticas constructivas y dar tutoría.

Desarrolle aplicaciones para el usuario y el futuro desarrollador

Ya sea que haya tenido la experiencia de una gran documentación y comentarios de código o no haya documentación o comentarios de código, puede ver cómo tanto la documentación como los comentarios son herramientas poderosas para ayudar a los futuros desarrolladores a navegar por el proyecto. Comparte el objetivo común de querer una aplicación fluida, funcional y SECA; mantener la documentación y dejar comentarios de código informativos es una buena manera de cerrar esa brecha.

Recuerde que su código también será heredado algún día

Ya he mencionado esto varias veces, pero es importante reiterar que su código también será heredado, sin importar lo seco y prístino que sean su código y lógica.

Lo más importante para llevar es ser flexible, humilde y que definitivamente puedes aprender nuevos trucos del código antiguo.