Una de las características de las metodologías ágiles, en particular de la Programación Extrema, es intentar resolver los problemas clásicos del desarrollo de SW teniendo en cuenta la psicología del desarrollador, pieza fundamental en todo lo ágil (Individuos sobre procesos). Todo gira en torno a la motivación y la actitud del desarrollador ante su trabajo. En este sentido está claro que documentar no es la tarea más agradable para un programador, y sí se supone que lo es escribir código (Software que funciona sobre documentación exhaustiva). Hay otros ejemplos, como la observación de que cuando un desarrollador tiene que probar el código después de haberlo implementado él mismo tiende a ser poco riguroso, hay una inclinación natural a no querer tener que volver atrás a corregir lo que ya se ha hecho. El simple hecho de escribir los tests antes que el código (TDD), según los agilistas, le da la vuelta a la situación.
Pero yo a lo que quiero referirme es al arte de escribir código de calidad. Últimamente algunos están aplicando un enfoque emocional al referirse a esto de escribir código mantenible. Se habla del código bello o de escribir código como una chica.
Mi pequeña aportación a todo ello es intentar desarrollar la idea de que el código bonito atrae código bonito, y el código feo atrae código feo. Es decir, que el código adecuadamente factorizado tiende a “mejorar con la edad”, a diferencia del código descuidado que tiende a empeorar:
Para argumentarlo recurro a mi propio análisis (completamente subjetivo) de la psicología del programador. Cuando un desarrollador se enfrenta a un código bien escrito, elegante, se siente de manera natural motivado a no estropearlo. Cualquier “mal olor” en un código perfumado llamará su atención y probablemente tratará de corregirlo. En consecuencia, la calidad del código tenderá a mantenerse o mejorar tras el cambio. La situación contraria se produce cuando el código con el que tienes que trabajar ha sido descuidado y tiene más que ver con el spaghetti code. Las sensaciones del programador aquí son un poco más desagradables. Los malos olores no llamarán la atención porque todo olerá mal. Y, por tanto, la motivación para refactorizar será pequeña. Probablemente, justificándote en la falta de tiempo y en el mal trabajo que hicieron otros antes que tú, introduzcas alguna chapucilla más que te permita quitarte el marrón de encima rápidamente. (Bueno, en realidad, esto no lo hacemos nunca, somos grandes profesionales…)
Sé que hay muchos otros factores que influyen en la curva del coste del cambio, pero para mí este es uno de los importantes. Finalmente, más allá de metodologías o tecnologías, el producto de nuestro trabajo son líneas de código a las que estamos condenados a volver algún día. Así es que, ¿por qué no escribir código para personas en lugar de para máquinas?
ATENCIÓN: Final de post con eslogan
Amigo, ¡Programa Bonito!
Actualización: (Parece que el tema está de moda, añado algunos links relacionados)
- ¿Cómo de limpia está tu casa?
- ¿Por qué debería yo reescribir código? (interesante la idea del desarrollador narcisista)
- ¿Qué hacen realmente los desarrolladores profesionales con su tiempo?
Search
About Putting it together
Blog acerca del desarrollo de software en la postmodernidad y la complejidad de mantener las cosas simples
Escrito por Luismi Cavallé
Las razones «teóricas» que esgrimes son perfectamente aceptables, pero mi impresión es algo diferente.
En principio estoy de acuerdo en que un código feo atrae al código feo. Es más, se trata de una característica vírica: si tienes una librería hecha a pegotes, es posible que todos los programas que la usen (incluso estando escritos por otras personas) también acabarán hechos chapuzas.
En lo que sí discrepo es en que el código bonito atraiga código bonito de manera segura. Esto sólo se da en contadas ocasiones, bien cuando todas las personas que escriben código se proponen (y saben) escribir código bonito. En el momento en que una persona empiece a flojear en esto o que el programador esmerado simplemente cambie de puesto o trabajo y su sustituto no esté a la altura el código comenzará otra vez la cuesta abajo —además con efecto bola de nieve—.
Es decir, que el programar código bonito es condición necesaria pero no suficiente para encontrar el círculo virtuoso de la perfección técnica.
De hecho el problema se agrava porque hay muchas definiciones de «código bonito». Para mí por lo general lo bonito es el código sencillo que hace exactamente lo que se pretende que haga. Otros, por el contrario, abstraen funcionalidad una y otra vez aprovechando todas y cada una de las filigranas que les permita el lenguaje de programación. Y ambos estilos de programacion casan mal: cuando en un mismo código han intervenido diferentes desarrolladores con diferentes estilos, es como esa paella dominguera en la que que todo el mundo ha metido mano pero que luego al final nadie se atreve a comer.
Muchas gracias por tu comentario, Juan, muy importante sobretodo como contrapunto a la visión idealizada que plantea mi post. El mundo real es mucho más oscuro que lo que planteo, sin duda, pero es precisamente por eso por lo que me agrada enfocar el asunto desde un punto de vista más relacionado con las sensaciones, con las emociones de las personas y la influencia de ello en el resultado de su trabajo.
Sin duda que tendrémos que poner los medios (talento, conocimientos, experiencia), nos tendrémos que poner de acuerdo en qué es código bonito (aunque tengo la sensación de que, a pesar de lo ambiguo de la expresión, todos nos hacemos una idea de a lo que nos referimos), y de cómo se consigue eso (esta es una de las ambiciones del blog). Pero en este caso me interesaba, simplemente, proponer un elemento motivador en la, demasiado a menudo, gris realidad del desarrollo de software.
“(aunque tengo la sensación de que, a pesar de lo ambiguo de la expresión, todos nos hacemos una idea de a lo que nos referimos)”
Desde luego: si bien encontrar una definición de “código bonito” no es trivial, cualquiera sabe reconocer un “código feo” en cuanto que se topa con él :(