Programacion extrema

Programación Extrema ¿Pero qué demonios es eso? La desconocida Programación Extrema es una metodología de programación que, en muchos casos, hace las cosas bastante más sencillas.

Nos enfrentamos a un nuevo proyecto y lo primero que hacemos es sacar lápiz, papel y pasar unas cuantas horas diseñando la estructura del proyecto, definiendo las relaciones internas y la interfaz de las diferentesclases y métodos. Después empezamos a programar propiamente dicho y en último lugar, y con menor importancia, finalmente testeamos nuestra aplicación. En teoría, y en teoría funciona el comunismo; pero sólo en teoría, este esquema es perfecto : Planificar, Construir y Buscar Errores (que no debería de haber ninguno). Pero si alguna vez lo has usado, sabrás que se cae por su propio peso en lamayoría de casos. Piensa en aquel momento que descubriste un error y tuviste que revisar cientos de líneas de código para taparlo, y la solución era un gran parche para no tocar el resto de tu super-código. O aquel en el que pasaste horas y horas definiendo métodos de clases que al final no llegaste a usar, porque en la práctica te saltaste toda esa teoría aburrida y en vez de unos setters decidistehacer públicas las variables y modificarlas "a pelo".

Ahí es donde interviene la programación extrema, haciendo el proceso más práctico que teórico. La programación extrema (a partir de ahora XP - eXtreme Programming - para facilitar las cosas) es perfecta para proyectos pequeños y medianos, pero es aún mejor para grandes proyectos o de alto riesgo.

¿En qué se diferencia entonces la XP de otrasmetodologías?
En la XP, la importancia de los test (para encontrar errores) y la experiencia del cliente (feedback) adquieren una mayor importancia, haciendo que se trabaje en ciclos de menor tiempo. Tranquilos que lo explicaremos todo.

A tomar por culo toda la teoría
La teoría está muy bien, pero es eso, "teoría". Sólo hay que ver que se inventaron los atributos public para las variables enlenguajes orientados a objetos, cuando "en teoría" todas deberían de ser privadas y controladas mediante setters y getters. Eso no significa que no piensen antes de empezar un proyecto. Es bueno (y necesario) hacer un mínimo esquema de cómo deben de ser las cosas y funcionar el sistema, pero no pasar horas y horas de organización (todo dependerá del tamaño del proyecto). Recuerda que pocaorganización es mala, pero en exceso también.

Los tests antes que el programa
La XP llevada al extremo implica que se escriban los test (debug tests) antes que la propia aplicación. Esto tampoco es estrictamente necesario, pero sin embargo hay "Tests Units Frameworks" que son una serie de tests pre-fabricados para aplicar directamente a tu aplicación. ¿Por qué?¿Por qué son tan importantes? Cuando seprograma de la forma old-school, uno deja para el final el testear su aplicación y encontrar errores. Esto significa que se le da una menor importante porque "en teoria" el programa no debería de fallar, aunque la realidad sea otra. Además suele ocurrir que al encontrar un fallo se aplica un parche que sólo ensucia el código y que ni siquiera se integra bien con el código. Sed sinceros, ¿cuántos devosotros ha creado variables y métodos especiales para solucionar un fallo, cuando podría haber utilizado parte de los recursos a existentes?¿Y después nos olvidamos de esas variables, sin borrarlas ni nada?

Testeando nuestra aplicación desde el primer momento, nos aseguramos de que el código escrito hasta entonces es correcto y no estropea lo anterior. La programación orintada a objetosfacilita esta tarea, ya que los objetos tienen una "interfaz" y deben responder ante ciertos "estímulos". Así por ejemplo, en un caso práctico, podríamos escribir los métodos vacíos de una clase, dentro de cada método escribir solamente el código necesario para que imprima por pantalla un mensaje que diga que se llegó a tal método o a tal otro. Y después, poco a poco, ir escribiendo el resto del...