Estrategias para trabajar con código legado

Por Dácil

El pasado 3 de marzo, Carlos Blé compartió su experiencia con código legado en la SD Summit, organizada por los amigos de Voxel Group

Te compartimos lo más destacable de la misma y también dejamos link al vídeo, por si quieres ver los ejemplos que se pusieron y las cuestiones que se plantearon.

Tip básico: Prohibido pensar que lo mejor es tirarlo todo abajo y rehacerlo al completo. Una buena cuestión que conviene plantearse sería: si lo rehaces al completo, ¿cómo puedes asegurar que no vas a estar en la misma situación dentro de un año?

Diez consejos que funcionan con el código legado

1. Si te encuentras frente a un lenguaje tipado (ej: Java con Intellij o C# con visual Studio), lo que infiere el IDE en la cantidad de refactor que haces es muy bueno y la posibilidad de que te equivoques es prácticamente nula.
2. Una gran parte de veces, el problema del código legado es que no lo entiendes. Propuesta: partir de un commit de una rama nueva desde la que no puedas estropear el proyecto y hacer refactoring para entender qué está pasando en el código. Es un ejercicio meramente exploratorio, esta rama deberías destruirla una vez ha cumplido su cometido de aprendizaje.
3. En aquellos casos en los que es imposible realizar test automáticos, es altamente recomendable disponer de un plan de pruebas manuales, aunque suene anticuado 😉
4. Si es factible escribir test automáticos, son muy útiles los end-to-end (cypress, selenium, etc) o aquellos que sean de ayuda a la hora de cubrir el “happy path”.
5. Acude a las costuras (seams), esos mecanismos que nos permiten “pinchar el teléfono” y enterarnos de lo que está pasando sin que la operativa normal se vea afectada.
6. Escribir test de “usar y tirar” puede ser otra herramienta exploratoria muy útil. No debemos perder de vista que un objetivo básico que tenemos con el código legacy es el de conocerlo a fondo, por lo que emplear algo de tiempo en realizar test que terminaremos desechando puede ser una muy buena inversión.
7. Haz pair programming. Cuatro ojos ven más que dos 😊 Recurre al control de versiones para intentar hacer pairing con quien escribió el código.
8. En aplicaciones muy grandes, ten presente que cambiar un código legacy lleva muchos años, es imposible dejar arreglado en seis meses algo que se ha escrito de cualquier manera durante diez años. Quizá lo que sí es viable es ir estrangulando la aplicación y reemplazando módulos. Resulta muy útil para este fin el patrón “Strangler Fig Application”
9. En aquellos casos en los que ha costado mucho descifrar lo que hace el código, es rentable añadir comentarios que lo documenten de forma breve… “este código hace X, a fecha XX”
10. Seamos pragmáticos y busquemos lo que es mejor en cada situación.

¡Esperamos que os sean útiles todos estos consejos!