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 incómodo, no lo quieres, te causa incomodidad, tampoco lo puedes echar, debes de vivir con él o a pesar de él, te demandará muchas horas. ¿Cómo vivir con eso?, te explico como:
El código representa conocimiento.
Toda línea 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 olvidarán que hacía. 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 cómo funciona o no funciona algo, entonces no querrás tocarlo o ser responsable por él. 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 empezarán a propagarse.
Todo código es reemplazable.
No existen vacas sagradas, ni los elefantes blancos en la programación. Ninguna línea de código es intocable. Sí, 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 por qué 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 más eficiente. Puedes empezar con dividir métodos gigantes en unidades más 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 válido.
Es más caro no hacer nada que mancharse las manos de lodo.
Tu inacción va a ser más 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 río abajo. El coste y esfuerzo para reparar un problema dispersado se incrementa exponencialmente entre más 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 está 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 revisiones 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 frecuente nos dicen que una cultura proactiva de prevención es mejor que una cultura de corrección.
Autor imagen: Siaron James
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20