The talking bit

A blog about programming, mainly PHP, and maybe other things


Project maintained by franiglesias Hosted on GitHub Pages — Theme by mattgraham

Legacy (Blogtober2019)

por Fran Iglesias

Mi compañera y manager en Holaluz Mavi Jiménez va a hacer un dibujo cada día del mes sobre una palabra propuesta en twitter. Y aquí vamos a intentar escribir un post por cada una de ellas.

Legacy

Creo que la mejor definición que se haya dado e código legacy es la de Michael Feathers: Legacy es código sin tests. Es simple, es operativa y es independiente de otras cuestiones.

To me, legacy code is simply code without tests.
Working Effectively with Legacy Code

Hay gente a la que el legacy parece molestarle. Es código feo, que requiere arremangarse y tener paciencia. Sí, es cierto que es código propenso a ocultar errores. Sí, es cierto que suele resultar confuso al leerlo. Sí, es cierto que requiere bastante trabajo de refactoring antes de ver que empieza a lucir un poco, o que le puedas introducir alguna nueva tecnología molona.

Sin embargo, como se suele decir:

Criticar el legacy es fácil. Muchas veces lo comparamos con lo que haríamos nosotros ahora, y por tanto, fuera de contexto:

Olvidando que ese código se creó en un momento dado de la historia del proyecto, con una serie de condicionantes que pueden explicar por qué se escribió así:

Sin embargo, creo que hay una manera de considerar el código que nos puede ayudar a ponernos en la disposición adecuada para trabajar con él.

El código es una representación del conocimiento

La visión del código como una representación ejecutable del conocimiento que tiene el equipo del negocio es muy potente. Esta visión contrasta con la de que el código es una mera solución técnica al problema del negocio, e implica una relación completamente distinta entre desarrolladores y dominio.

En cada momento, el código nos habla de dos cosas:

  • La representación del dominio en un modelo ejecutable, expresado en forma de código, más o menos articulada según el conocimiento que comparten desarrolladores y expertos de dominio.
  • Las limitaciones de la tecnología o lenguaje utilizados, y la fluidez de los desarrolladores, para realizar ese modelo. O dicho de otra forma: la capacidad que tienen los desarrolladores de expresar el modelo en el lenguaje de programación utilizado.

Según esto, podemos analizar el legacy como un código que representa un conocimiento del negocio en un momento anterior de la historia del proyecto. En ese momento puede ocurrir que ciertos conceptos no estén bien representados o desarrollados, o que ciertas relaciones no se habían establecido o han cambiado desde entonces. Además existen limitaciones en los lenguajes que se pueden rastrear en las bases de código, atendiendo a la versión del lenguaje de programación disponible en un momento dado o incluso a los patrones y teorías de diseño dominantes.

Piensa en el código como en el conocimiento científico: siempre es perfeccionable y, de hecho, se ha perfeccionado históricamente. En ese perfeccionamiento han influido muchos factores, entre ellos las herramientas disponibles, tanto las intelectuales, como el método científico o la filosofía de la ciencia, como el alcance, resolución y precisión de los instrumentos de medida. Los cambios en el conocimiento científico reflejan esos avances.

En ese sentido, el problema con el legacy aparece cuando éste se queda estancado y no evoluciona a la vez que lo hace el conocimiento del negocio. Esto puede ocurrir si hay un parón en el desarrollo, o si es un software encargado a una empresa externa que lo entrega y no sigue desarrollándolo, o si el equipo de desarrollo original desaparece de forma más o menos brusca, sin que se haya producido un relevo. Cuando el desfase entre el modelo representado por el legacy y el conocimiento del negocio es muy grande, cabe plantearse que puede ser mejor opción iniciar un proyecto nuevo que sustituya progresivamente al anterior.

Mirado de esta forma, el legacy deja de ser legacy y el código nuevo deja de serlo también. Se trata simplemente de instantáneas de nuestro conocimiento del dominio. Si creemos que hay un desfase entre lo que el código dice y lo que sabemos, nuestro trabajo es reducirlo.

October 29, 2019

Etiquetas: blogtober19  

Temas

php good-practices blogtober19 testing refactoring tdd design-principles legacy misc design-patterns bdd tips python ddd tools soft-skills bbdd api sql ethics testing, swift javascript