Código heredado, un problema que necesita de herramientas

El fundador y director ejecutivo de Akita, Jean Yang, define el software heredado en una frase tan simple como “es lo que otras personas escriben para que otros usen. En el momento en que se envía un código, hay un software heredado”. Además, prosigue: “No recuerdo ni las cosas que hice la semana pasada, por lo que en el caso de los desarrolladores pasa lo mismo”:

Normalmente pensamos en esta forma de legacy como aplicaciones escritas en COBOL y ubicadas en algún mainframe en alguna parte. Este tipo de pensamiento lleva a los creadores a desarrollar código de forma miope, sin pensar en quién tendrá que leer su trabajo más tarde. Como señala Yang, esto incluye a casi todos. Por lo tanto, cabe preguntarse cómo podemos ser más inteligentes con el código heredado.

Llamadas de red y complejidad

Un problema con el código es que nunca es realmente estático. Cada vez que salta a la red está en una tierra misteriosa y pierdes el control, pero en el momento en que necesitas que sea útil se desata el infierno porque se introducen complejidades en la aplicación, tal y como reseña Charity Majors, cofundadora y CTO de Honeycomb. Majors argumenta que no se puede saber realmente cómo se va a comportar el software hasta que se pone en producción, cuando se revelan las grietas de esa herencia. “Una pequeña pieza de código es un sistema complicado, pero una vez que tiene usuarios y patrones de tráfico y una infraestructura diferente debajo, se vuelve difícil de gestionar”. Y complejo en formas que introducen “incógnitas desconocidas. No puedes predecir lo que va a pasar cuando cambias algo, tienes que cambiarlo y observar y ver qué sucede en un entorno complicado”.

Problemas de personas, no de código

Como destaca la propia Majors, “los ingenieros individuales pueden escribir software pero solo los equipos pueden entregarlo, mantenerlo y poseerlo. La unidad de envío más pequeña de entrega de software es el equipo”. Podemos engañarnos a nosotros mismos pensando que los problemas son técnicos en la aplicación, pero en realidad son humanos. Esto nos lleva de vuelta a la herencia y a lo observable.

Entendiendo el legacy

“El coste de encontrar y solucionar problemas en el software aumenta exponencialmente cuanto más tiempo ha pasado desde que se escribió”, señala Majors. Como tal, las herramientas para observar pueden ser críticas para ayudar a solucionar problemas en minutos mediante la ejecución de código en producción controlada, lo que permite a los desarrolladores depurar su código heredado poco después de escribirlo en lugar de intentar descifrarlo meses, años o incluso décadas después.

Esta es también la cual una buena documentación es tan esencial. A veces pensamos que solo es para ayudar a otros con el código que se ha construido, lo cual es cierto, pero también ayuda a recordar por qué se escribió el código de cierta manera. “Cuando vuelvo al proyecto en unos meses todo funciona y sé dónde está”, dice el fundador de Datasette, Simon Willison.

Buenos documentos, buenas pruebas unitarias y buena observabilidad. “Parte del desarrollo es la operación”, dice Majors, “y ver cómo se comporta bajo diferentes sistemas y restricciones”.

¿Qué pasa con aquellos que miran su código y tratan de ejecutarlo años o décadas después? Incluso para aquellos que no creen que esto se aplique a ellos, consideren lo que  Avishai Ish-Shalom argumentó recientemente; nuestra infraestructura "moderna" como Linux, MySQL, PostgreSQL, etc., tiene décadas de antigüedad, e incluso las nubes "modernas" son en su adolescencia media ahora. Lo que es más preocupante, dijo, "esta infraestructura, si bien ha demostrado ser notablemente más flexible y estable que nuestras predicciones más optimistas, está mostrando signos de óxido y vejez, lo que hace que el mantenimiento y el desarrollo sean más desafiantes año tras año".