Toda pieza de software está destinada a ser descartada en algún momento de su vida útil. Los sistemas son sustituidos por otros nuevos y mejores, al menos en la teoría. La sustitución de un programa representa en algunas empresas la oportunidad de empezar de nuevo, no hay que lidiar con legados, ni con errores heredados. Puedes construir a tus anchas sin miedo; casi todos los programadores, si pueden elegir entre un proyecto de tipo «green field» o un «brown field» elegirán el primero. Hay que ser cuidadosos a la hora de plantear un sistema nuevo que reemplazara al obsoleto, esto tiene implicaciones que debes de considerar. A continuación te las menciono.
Escribir nuevas líneas de código es fácil. Demasiado fácil.
Cualquiera puede tirar de líneas que resuelva un problema, es el requisito mínimo para ser considerado programador. Es tentador ser el programador que puede ofrecer la solución que saque a la empresa del lodo de los legados, construyendo un nuevo sistema que no tendrá los errores del anterior. En raras ocasiones se contempla el construir a partir de lo existente, o ver los motivos por los cuales el sistema anterior fallo. Por lo general se apunta al programador anterior, aquel fue el malo. El equipo anterior cometió errores imperdonables y obvios, que el nuevo no hará y, por lo tanto, entregara una mejor solución. Pero, ¿de verdad se sabe cómo funciona el sistema?
Todo sistema representa conocimiento adquirido.
Aunque no se vea, todos los sistemas guardan conocimiento acerca de como funciona, o debe de funcionar la empresa. No siempre este conocimiento es obvio y fácil de leer. Un código de mala calidad suele ocultar que es una regla de negocio, un bug, o parte del diseño de la aplicación. Si la meta de un programador es replicar un sistema a partir de otro sistema que no es claro en su funcionamiento, es seguro que habrá fallas y bugs. Los problemas empezarán a surgir en el momento que los flujos no puedan ser completados o el camino ideal del programa tenga variantes inesperadas. Es común oír de tus clientes internos él: «es que el sistema anterior hacia esto» o «¿por qué no está X función?, si antes si estaba». Si, no puedes saber todos los caminos posibles del sistema, desgraciadamente los faltantes o malentendidos van a comenzar a generar desconfianza en el sistema nuevo que no iba a tener errores.
Dale la importancia que se merece al sistema actual.
Un sistema que funciona mal o deficientemente, pero funciona, es indistinguible de un sistema que funciona bien para el usuario final. Tus usuarios y tus clientes internos pueden esperar la misma funcionalidad que ofrecía el anterior. Puede que mejores un proceso o un flujo de trabajo y el cambio sea impopular, porque ya todos estaban acostumbrados al flujo anterior. Presta atención a los flujos de trabajo y el uso que le están dando tus usuarios. Registra los problemas y desperdicios que se presenta el aplicativo actual (siempre desde la perspectiva del usuario, no la tuya), de ser posible no cambies la interfaz gráfica a menos que sea estrictamente necesario. Los usuarios acostumbrados a un flujo de trabajo suelen presentar resistencia e incluso oposición a los cambios. La perdida de conocimiento o la ignorancia se considera un desperdicio en los proyectos de mejora.
No tienes que tirar todo el sistema anterior.
Siempre hay riesgo en reemplazar aplicaciones que no conoces al 100 %, la perdida de funcionalidad o conocimiento es un problema común. Puedes construir funcionalidades nuevas o agregar mejoras a los sistemas actuales desde adentro, sin tener que añadir construcciones nuevas a las arquitecturas de la empresa. La opción de desmantelar el sistema desde dentro tiene la ventaja de que puedes ofrecer exactamente el comportamiento esperado sin el coste de quemarte por fallas que prometiste no cometer. Las expectativas de tus clientes internos y tus usuarios son menores. Vas a comenzar convirtiendo la aplicación monolítica en módulos que pueden estar desacoplados lógica o físicamente. Cualquier modulo que no puedas refactorizar puede quedarse funcionando sin que lo toques.
El hábito de reparar y mejorar siempre es mejor que volver a construir.
Siempre es mejor opción pagar la deuda técnica que has heredado, antes que volver a contraer más deuda. En el fondo un sistema nuevo construido a partir de otro es deuda técnica en otro sabor.
La acción de guerrilla de reparar, luego refactorizar y desacoplar, después agregar pruebas automatizadas y por último recibir feedback reporta mayores beneficios a la larga. Los sistemas se vuelven complejos e inestables por un bajo compromiso del equipo para mantener la calidad. Tener dos sistemas, el nuevo y el viejo con altas cantidades de deuda técnica que pagar, solo ocasiona problemas. Si las aplicaciones anteriores tuvieron bajo compromiso de sus programadores, las nuevas tendrán ese mismo destino.
Conclusiones.
El principal enemigo del programador es la complejidad. Es muy fácil que un sistema se haga complejo en muy poco tiempo, en cambio, es muy difícil hacer que una pieza de software reduzca su nivel de complejidad. El hábito de corregir y reparar en el menor tiempo posible los problemas del día a día, te previenen de llegar a la situación de tener que construir algo de nuevo.
Si no tiras la basura de tu casa periódicamente, pronto esta se llenara. Tienes dos opciones: vas y compras una casa nueva o… periódicamente esperas el camión y se la entregas.
Autor imagen: Albert Koch
- 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