[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.