No seas esclavo del código legado.

El código legado es todo aquel que fue escrito antes de que llegaras al equipo, por alguien que no fuiste tu y que esencialmente no sabes muy bien como funciona. En esta definición entra la mayoría de los sistemas escritos, por desgracia. El código legado es un familiar incomodo, no lo quieres, te causa incomodidad, tampoco lo puedes echar, debes de vivir con el o a pesar de el, te demandara muchas horas. ¿Como vivir con eso?, te explico como:

El código representa conocimiento.

Toda linea de código describe el funcionamiento de la empresa y luego de los sistemas. Por lo general el conocimiento acerca de como funcionan los sistemas lo poseen los programadores. Eventualmente estos se irán, serán sustituidos por otros, u olvidaran que hacia. Inevitablemente aparecerán lagunas de ignorancia en la organización. La ignorancia lleva al miedo y a la evasión de los problemas. Si no sabes como funciona o no funciona algo, entonces no querrás tocarlo o ser responsable por el . Empieza a surgir el usar caminos alternos como opción para los nuevos desarrollos. Es de vital importancia suprimir las lagunas de desconocimiento cuanto antes o empezaran a propagarse.

Todo código es reemplazable.

No existen vacas sagradas, ni los elefantes blancos en la programación. Ninguna linea de código es intocable. Si, existen riesgos y consecuencias de cambiar algo. Modificar sistemas legados puede llegar a convertirse en una operación quirúrgica y milimétrica. Donde un fallo por mínimo que sea puede ser catastrófico. Postergar la resolución de problemas detectados para cuando se tenga tiempo, lo único que consigue es elevar la factura por la reparación de estos. Si el código no es el apropiado, lo correcto es reemplazarlo en el menor tiempo posible.

Un elefante se come un bocado a la vez.

No tienes porque comerte el sapo de una sentada, la clave para mantener legados es visualizar un flujo de trabajo constante y sistemático a modo de guerrilla. Debes de construir procesos de monitoreo que garanticen el estado del sistema ante una posible refactorización. Si el sistema es mejorado sin cambiar su comportamiento original, no tendrás resistencia por parte de otras áreas. Las pruebas de regresión son vitales, aun si no vas a refactorizar. Si tienes un mecanismo de validar un comportamiento anterior puedes descartar síntomas de manera mas eficiente. Puedes empezar con dividir métodos gigantes en unidades mas pequeñas. También puedes detectar y desmantelas clases dios. Dividir ensamblados o juntarlos, según sea el caso. Cualquier inicio que mejore la comprensión y clarifique el conocimiento es valido.

Es mas caro no hacer nada que mancharse las manos de lodo.

Tu inacción va a ser mas costosa en el largo plazo, un problema puede ser síntoma no la enfermedad misma. Así como la luz de motor en el tablero de tu auto no es el problema real, si ignoras la alerta no te quejes cuando debas hacer una reparación mayor. No modificar los sistemas puede llevar a los siguientes problemas:

  • El problema puede ir rió abajo. El coste y esfuerzo para reparar un problema dispersado se incrementa exponencialmente entre mas lejos llegue. Sin contar el incremento de la deuda técnica resultante.
  • Iniciar nuevo trabajo con problemas activos. Si no hay garantías de alguna corrección todo nuevo trabajo esta sujeto a incluir defectos.
  • El problema no ha sido ubicado y continua la operación. Toda el área podría tener el mismo problema, una detección tardía puede llevar a correcciones posteriores en trabajo que ya se consideraba hecho.

Conclusiones.

Un argumento común para no reparar legados es el coste, es muy caro modificar eso. Es posible, la pregunta es: en el largo plazo, ¿que tan costoso es permitir bugs en los legados?, ¿que tan caro es no saber que hacen exactamente los sistemas de la empresa?, ¿son asumibles los defectos en el sistema por los clientes?, ¿es preferible ahorrar unas monedas aun si la calidad de los productos de la empresa se verán comprometidos?. Las respuestas a estas preguntas son subjetivas, y obviamente van a variar. La experiencia y el sentido común nos dicen que una cultura pro activa de prevención es mejor que una cultura de corrección.

Autor imagen: Siaron James