Putting it together

by Luismi Cavallé

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)

  1. ¿Cómo de limpia está tu casa?
  2. ¿Por qué debería yo reescribir código? (interesante la idea del desarrollador narcisista)
  3. ¿Qué hacen realmente los desarrolladores profesionales con su tiempo?