Programacin extrema

Un poco de historia En los tiempos en que la informtica empez a hacerse popular, en el que slo haba pantallas de texto, no haba entornos de ventanas y las impresoras usaban papel con agujeros a los lados y rayas horizontales, las aplicaciones eran bastante ms sencillas que las actuales. Bastaba uno o dos programadores, que totalmente a su aire y en un plazo razonable de tiempo eran capaces de hacer programas tiles. Para imprimir una lista de clientes, bastaba pulsar en el men el "1" de imprimir, luego el "3" de clientes y echarle un ojo a la impresora para ver si imprima o no. El programador era una especie de "mago" que haca su aplicacin y slo l saba cmo funcionaba. Si acaso, y para cubrir el expediente, despus de hacer el programa haca un "flujograma" de los antiguos, no haba UML, orientacin a objetos ni cosas por el estilo. Con el tiempo, las aplicaciones fueron siendo cada vez ms exigentes, los ordenadores disponan de ms memoria y aparecieron los entornos de ventanas. Ahora para imprimir la lista de clientes, haba que arrastrar el icono del "seor gordo con bigote" sobre el icono de la impresora, haciendo que caminara "como un egipcio" mientras lo arrastrabamos con el ratn (otro invento nuevo). La impresora deba imprimir grficos, con negritas, cursivas y 32 fuentes simultneamente. Adems, hay que hacer que los altavoces estereos toquen msica polifnica mientras se arrastra al "gordo del bigote". Todas estas complicaciones hicieron que los programas se agrandaran y complicaran enormemente, que hicieran falta varios desarrolladores y tiempos de desarrollo ms largo. Todo esto llev consigo la necesidad de ms organiazacin y ms papeleo. Aparecieron las metodologas de desarrollo ms pesadas (las que se basan en escribir mucha documentacin). Antes de hacer un programa, fue necesario escribir qu es lo que se quera hacer, de forma que asegurbamos que el cliente y los desarrolladores estaban de acuerdo en lo que se iba a hacer. Luego haba que escribir qu se iba a hacer, para que los muchos programadores trabajaran ms o menos con un objetivo comn y organizados, etc, etc.
Prcticas bsicas de la programacin extrema Para que todo esto funcione, la programacin extrema se basa en trece "prcticas bsicas" que deben seguirse al pie de la letra. Dichas prcticas estn definidas (en perfecto ingls) en www.xprogramming.com/xpmag/whatisxp.htm. Aqu tienes un pequeo resumen de ellas

Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto. Planificacin: Se hacen las historias de usuario y se planifica en qu orden se van a hacer y las mini-versiones. La planificacin se revisa continuamente. Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las miniversiones.

Versiones pequeas: Las mini-versiones deben ser lo suficientemente pequeas como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo til al usuario final y no trozos de cdigo que no pueda ver funcionando. Diseo simple: Hacer siempre lo mnimo imprescindible de la forma ms sencilla posible. Mantener siempre sencillo el cdigo. Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario). Desarrollo guiado por las pruebas automticas: Se deben realizar programas de prueba automtica y deben ejecutarse con mucha frecuencia. Cuantas ms pruebas se hagan, mejor. Mejora del diseo: Mientras se codifica, debe mejorarse el cdigo ya hecho con el que nos crucemos y que sea susceptible de ser mejorado. Extraer funcionalidades comunes, eliminar lneas de cdigo innecesarias, etc. Integracin continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequea funcionalidad, debe recompilarse y probarse. Es un error mantener una versin congelada dos meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando falle algo, no se sabe qu es lo que falla de todo lo que hemos metido. El cdigo es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del cdigo. Para eso se hacen las pruebas automticas. Normas de codificacin: Debe haber un estilo comn de codificacin (no importa cual), de forma que parezca que ha sido realizado por una nica persona. Metforas: Hay que buscar unas frases o nombres que definan cmo funcionan las distintas partes del programa, de forma que slo con los nombres se pueda uno hacer una idea de qu es lo que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a que todos los programadores (y el cliente) sepan de qu estamos hablando y que no haya mal entendidos. Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto quiere decir que no debe haber das muertos en que no se sabe qu hacer y que no se deben hacer un exceso de horas otros das. Al tener claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario o mini-versin.