Introducción a la Programación 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 diferentes clases 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 la mayorí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 decidiste hacer 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 otras metodologí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 en lenguajes 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 poca organizació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 se programa 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 teoŕia" 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 de vosotros 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 objetos facilita 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 código.


Haz compartimentos estanco
Si todo tu programa es una gran bola de código inentendible, cuando haya un agujero te entrará agua y te hundirás en la balsa. Si por el contrario tu barquichuelo está hecho a base de compartimentos estancos y uno está agujereado, seguirás a flote porque el resto no se inundará. Hacer pequeños trozos independientes de un programa es casi una obligación de nuestros tiempos y una de las bases de la XP. Tanto si trabajas en solitario como en un grupo, las ventajas son infinitas. Si trabajas en grupo, cada uno de tus compañeros puede trabajar en un apartado diferente del programa ahorrando tiempo de desarrollo, además al ser "independientes" si falla un "módulo" del programa, sólo se necesita reparar ese módulo, el código estará localizado en un grupo de archivos menor y se solucionará con mayor rapidez. Haz módulos según necesites.

Consulta con el cliente
El feedback es importante, y la XP lo potencia al máximo. Si el programador idea una forma de ir desde A hasta C pasando por B, el cliente o el usuario encontrará la forma de ir directamente de A a C generando errores por el camino. A cada poco se suelta una beta para testeo, con la información resultante de los testeadores se hace una "pequeña" release. Pequeños cambios implican pequeños errores que se solucionan en menor tiempo. Esto va acorde con el de hacer pequeños módulos en el programa, y se van probando los módulos uno a uno según su desarrollo.

En grandes proyectos y de riesgo, utiliza la XP
¿Tienes un gran proyecto?¿Algo nuevo para tu equipo de desarrollo?¿Para la industria del software?¡La XP es para tí! La XP proporciona un camino fácil para alcanzar metas simples a corto plazo que formen parte de un proyecto a mayor escala. Con la XP puedes establecer mejores roadmaps (planes de desarrollo y tiempos de entrega) tener un mejor control sobre el producto porque a cada paso que des tendrás un producto funcional, no tan completo como el proyectado, pero funcional.

Conclusiones
La XP está ahí afuera. Es un recurso útil y al igual que muchos de los patrones de programación (MVC, Singleton, ...) posiblemente estés usando ya parte de la XP en tus proyectos a diario, pero nunca viene mal conocer algunos consejos extra para hacernos más ágiles en el desarrollo de software.

Más información

• ExtremeProgramming.org
  
• XProgramming.com

¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.