Marzo 28, 2005

[XP] Propiedad colectiva del código, tests, y coding standards

Extreme Programming (que es casi más una filosofía que un método de desarrollo) se basa en doce prácticas.

Desde mi punto de vista, una de las prácticas fundamentales es la "propiedad colectiva del código".

¿Pero, qué quiere decir eso?. Pues, como el nombre indica, el código no es propiedad de quien lo escribe, sino que cualquier miembro del equipo puede ( y de hecho debe ) mejorar cualquier parte del código en cualquier momento.

Esta forma de atacar el desarrollo tiene bastantes ventajas, se programe en parejas, o de forma individual. En primer lugar, se evitan los cuellos de botella. Además, si se ve alguna parte del código que necesita ser mejorada, se debe hacer lo antes posible, sin importar quién lo escribiera. De esta forma, el código tiende a simplificarse y hacerse más sencillo, pero no sólo en segmentos concretos del mismo, sino que todo el código del proyecto en general va mejorando, ya que se está refactorizando contínuamente. Esas refactorizaciones, además, son mucho más simples de realizar, ya que el conocimiento sobre el proyecto se va repartiendo entre todos los miembros del equipo. También, la productividad de ese equipo mejora, ya que todo el mundo puede ayudar a cualquiera en cualquier momento, y el nivel de frustración tiende a bajar ( si eso es posible en un programador ), ya que no hay parones, ni se puede culpar a nadie de que algo no funciones correctamente.

Pero para conseguir llevar a cabo esas "buenas intenciones", hay dos aspectos sobre los que ha habido que trabajar con anterioridad: los tests, y los estándares en la estructura del código.

Se va a trabajar en un equipo que va a estar contúnuamente refinando el código. Por tanto, tiene que haber una forma de asegurarse que los cambios que se vayan realizando no van a llevar al proyecto a un punto en el que nada funciona y no se puede volver atrás. Así que debe haber una serie de tests que permitan ir probando lo que se va cambiando. De hecho ( aunque eso es materia para otro post ), esos tests deberían realizarse antes de comenzar a escribir el código real. Debería haber un test para cada clase antes incluso de escribir esa clase. De esta forma, cuando alguien cambie una clase, sólo tiene que volver a correr el test. ¿Que todo funciona bien?. Pues a otra cosa.

Pero además, si todos van a poder modificar el código, éste tiene que estar escrito en un lenguaje que todos entiendan ( y no me refiero a lenguaje de programación, sino a la forma en que está escrito el código ). Si voy a tener que cambiar lo que ha escrito otra persona, lo mejor es que esté escrito como si fuera mío: nombres de variables similares, nombres de métodos similares, la misma disposición de paréntesis, llaves, corchetes, saltos de línea, incluso de espacios en blanco. Esos estándares pueden ( mejor, deben ) estar definidos y consensuados por todo el equipo, por todos los que los van a utilizar.

Por cierto, herramientas como Eclipse, facilitan mucho el trabajo a la hora de definir los estándares de código. Basta con definir unas preferencias ( Ventana->Preferencias->Java->Code Style ) y exportarlas después a todos los ordenadores de los miembros del equipo.

Escrito por Cesar Tardaguila en: Marzo 28, 2005 07:53 AM | TrackBack
Comentarios