¿Qué es el código heredado y cómo trabajar con él?
Fuente: Dou Tarde y temprano, un programador probablemente tendrá que encontrar código heredado. Para aliviar las consecuencias de este conocimiento, he seleccionado algunos consejos prácticos y ejemplos de mi propia experiencia, en particular, trabajando con un sistema Java heredado.Funciones heredadas
El legado es el código de otra persona, que a menudo es tan terrible que generalmente no está claro cómo trabajar con él. Y si tienes que trabajar con un sistema heredado, además del código antiguo, también encontrarás:- con tecnología obsoleta;
- arquitectura heterogénea;
- falta o incluso ausencia total de documentación.
-
No podemos faltarle el respeto a un sistema que genera millones y al que acceden miles de personas al día. No importa lo mal escrito que esté, este código repugnante sobrevivió hasta la producción y funciona las 24 horas del día, los 7 días de la semana.
-
Dado que este sistema genera dinero real, trabajar con él conlleva una gran responsabilidad. Esto no es una startup, sino algo con lo que los usuarios trabajarán mañana. Esto también implica un costo de error muy alto, y la cuestión aquí no está en las afirmaciones del cliente, sino en la situación real.
Ingeniería inversa
Para trabajar con éxito con código heredado, deberá utilizar técnicas de ingeniería inversa. Primero, debe leer atentamente el código para comprender exactamente cómo funciona. Esto es obligatorio, porque lo más probable es que no tengamos documentación. Si no entendemos el hilo de pensamiento del autor, haremos cambios con consecuencias impredecibles. Para protegerse de esto, también debe profundizar en el código adyacente. Y al mismo tiempo avanzar no sólo en amplitud, sino también en profundidad. ¿Dónde se llama al método con el error? ¿De dónde viene el código que lo llama? En un proyecto heredado, la "jerarquía de llamadas" y la "jerarquía de tipos" se utilizan con más frecuencia que cualquier otra cosa. Tendrá que dedicar mucho tiempo al depurador: en primer lugar, para encontrar errores y, en segundo lugar, para comprender cómo funciona todo. En cuanto a la documentación, no sería mala idea recurrir a la arqueología industrial. Puede resultar muy útil buscar documentación antigua en algún lugar y hablar con quienes recuerdan cómo se escribió el código heredado. Al utilizar estas técnicas, tarde o temprano comenzarás a comprender más o menos el código. Pero para evitar que sus esfuerzos se desperdicien, debe documentar inmediatamente los resultados de su investigación. Para ello, recomiendo dibujar diagramas de bloques o diagramas de secuencia. Por supuesto, serás vago, pero definitivamente necesitas hacer esto; de lo contrario, después de seis meses sin documentación, estarás investigando este código como si fuera la primera vez.
No reescribas el código
Lo más importante en el proceso de desarrollo es castigarse a tiempo y no intentar reescribir todo el código desde cero. Estime cuántos años-hombre requerirá esto. Es poco probable que el cliente quiera gastar tanto dinero en rehacer algo que ya funciona. Esto se aplica no sólo al sistema en su conjunto, sino también a cualquier parte del mismo. Por supuesto, es posible que te den una semana para resolverlo todo y otra semana para arreglar algo. Pero es poco probable que le den dos meses para volver a escribir parte del sistema. En su lugar, implemente la nueva funcionalidad con el mismo estilo que el resto del código. En otras palabras, si el código es antiguo, no debería caer en la tentación de utilizar tecnologías nuevas y hermosas: dicho código será muy difícil de leer. Por ejemplo, puede encontrarse con una situación como la nuestra: parte del sistema está escrita en Spring MVC y otra parte está escrita en servlets simples. Y si en una parte escrita en servlets es necesario agregar algo más, lo agregamos de la misma manera: en servlets.Respetar los intereses comerciales
Hay que recordar que cualquier tarea está determinada, en primer lugar, por el valor para el negocio. Si no demuestra al cliente la necesidad de realizar ciertos cambios desde el punto de vista comercial, estos cambios no se producirán. Y para convencer al cliente hay que intentar ponerse en su lugar y comprender sus intereses. En particular, si desea refactorizar sólo porque el código es difícil de leer, no se le permitirá hacerlo y tendrá que vivir con ello. Si realmente no puedes soportarlo, puedes reorganizar el código silenciosamente y poco a poco, repartiendo el trabajo entre los tickets comerciales. O convencer al cliente de que esto, por ejemplo, reducirá el tiempo necesario para encontrar errores y, por tanto, en última instancia, reducirá los costes.Prueba
Está claro que las pruebas son necesarias en cualquier proyecto. Pero cuando se trabaja con sistemas heredados, se debe prestar especial atención a las pruebas, también porque el impacto de los cambios realizados no siempre es predecible. Necesitará al menos tantos evaluadores como desarrolladores; de lo contrario, debería ser increíblemente bueno en la automatización. En nuestro proyecto, las pruebas constaron de las siguientes fases:- Verificación, cuando la funcionalidad implementada de una característica se verifica en una rama separada.
- Estabilización, cuando se marca una rama de lanzamiento en la que todas las funciones se fusionan.
- Certificación, cuando se vuelve a ejecutar lo mismo en casos de prueba ligeramente diferentes en un entorno de certificación lo más cercano posible a la producción en términos de características y configuración de hardware.
Formalizar DevOps y lanzar
El procedimiento de liberación podría ser, por ejemplo, el siguiente. Cuando finaliza el desarrollo y se han completado dos o tres fases de prueba, escribimos un correo electrónico al equipo de DevOps 36 horas antes de la hora de lanzamiento prevista. Después de esto, llamamos al equipo devops y discutimos todos los cambios en los entornos (les informamos sobre todos los cambios en la base de datos y la configuración). Para cada cambio disponemos de un documento (un ticket en Jira). Luego, durante el lanzamiento, todos los involucrados en esto se reúnen y todos dicen lo que están haciendo ahora: "Subimos la base de datos", "Reiniciamos tal o cual servidor", "Fuimos a ejecutar pruebas de regresión en el entorno de producción". " Si algo sale mal, se inicia el procedimiento de reversión de la versión, descrito exactamente en el documento de versión original; sin dicho documento definitivamente olvidaremos algo o nos confundiremos.Controlar la calidad del código.
Y por último, la revisión de código es una práctica que por alguna razón no se utiliza en todos los proyectos. Es fantástico si cada fragmento de código es revisado por más de una persona. Incluso en un equipo muy fuerte, siempre se descubren algunos errores durante el proceso de revisión del código, y si varias personas lo miran, la cantidad de errores identificados aumenta. Además, a veces el tercer o cuarto revisor encuentra lo peor.Herramientas que facilitan la redacción de documentación técnica
Fuente: Dzone A la mayoría de los programadores no les gusta escribir documentación técnica. El experto en psicología Gerald Weinberg incluso llamó a la documentación “el aceite de ricino de la programación”: a los desarrolladores les encanta leerla, pero simplemente odian escribirla ellos mismos.
La falta de orientación o una hoja de ruta en blanco da como resultado una falta de información sobre cómo funcionan las diferentes partes del software. En última instancia, esto empeora la experiencia de los usuarios finales del código porque, en ausencia de documentación, no pueden confiar en la precisión y utilidad del producto. Para que a los programadores les resulte más fácil adquirir el hábito de escribir documentación, recomiendo prestar atención a cuatro excelentes herramientas que ahora están disponibles para casi todos.
GO TO FULL VERSION