Programación extrema

Los desarrolladores de software (en cualquier lenguaje de programación) siempre hemos establecido nuestra estrategia en el siguiente modelo: recabar información, programar, depurar e implantar. Un cliente te pide una aplicación a medida y te reúnes con él para obtener todos los datos necesarios para su desarrollo: formularios, informes, estadísticas, estructuras de datos, etcétera. Posteriormente dedicas el tiempo necesario a la programación en sí para, después, pasar a la fase de depuración de los mil cien errores que aparecerán (mil cien exactos, sí), parcheando el código pertinente. Por último se instala el software compilado en la máquina o máquinas del cliente, dándole los últimos retoques si fuera necesario (siempre lo será, incluso tres meses después de la implantación).

Este modelo de desarrollo es de todo punto ineficaz. Es más que común realizar un diseño previo a la programación y que luego, a la hora de escribir código, vayan apareciendo errores o escollos de ese diseño inicial que se salvan rehaciendo el código afectado y añadiendo pegotes que hacen que, al final, el código y el diseño no se parezcan en nada.

El modelo de programación extrema (o XP, de eXtreme Programming) no intenta evitar que lo anterior ocurra, porque sabe que es imposible luchar contra ello. Lo que hace, en cambio, es tratar de adaptarse a esas circunstancias.

La programación extrema (sin casco) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia: Extreme programming explained: embrace change (Prentice-Hall, 1999). Es un proceso ágil de desarrollo de software que se basa en una serie de pilares, entre los que destacan el trabajo estrecho con el cliente desde el minuto 1 y la pruebas o test continuos. El cliente se sumerge de tal forma en el proceso de creación que va a terminar por parecer un miembro más del equipo de desarrollo, y el proceso de testeo será tan intenso como la propia programación en sí.

La programación extrema es tan extrema que recomienda realizar la depuración antes incluso que la propia aplicación, haciendo pruebas cada poco tiempo tras terminar pequeños bloques de programación. En estas pruebas, por supuesto, el cliente estará también involucrado al cien por cien.

En un proceso de desarrollo con XP (la XP, no Windows XP) el cliente se reúne con los programadores y definen lo que se va a hacer, como en el modo de programación old school. Sin embargo, aquí es el cliente quien documenta (literalmente escribe) lo que debe realizar el programa, y no se lo cuenta al programador y éste lo transcribe como en los modelos clásico. A este proceso se le conoce como «historias del usuario», que deben ser una o dos frases cortas en el lenguaje coloquial del usuario que expliquen claramente lo que realizará tal o cual proceso. Las historias del usuario son una forma rápida de administrar los requerimientos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Además, permiten responder rápidamente a los requerimientos cambiantes.

Después de esto, los programadores, por parejas, se ponen inmediatamente a trabajar y desarrollan en poco tiempo un bloque estanco de código (compatible y complementario con el código anteriormente generado) que responda a los requerimientos de la historia del usuario redactada. Cada cierto tiempo, no más de dos o tres semanas, se compila el código fuente y se genera una porción del software total que se depura con el cliente. En el momento en que cada bloque responda a las expectativas del usuario, se pasa a otro bloque nuevo, estableciendo una estructura modular, libre de errores en cada módulo, que combina perfectamente y es robusta y versátil. Este ciclo se va repitiendo una y otra vez hasta que el cliente se dé por satisfecho y cierre el proyecto.

La programación por parejas es uno de los principios más radicales de la XP. Requiere que todos los programadores XP escriban su código en parejas, compartiendo una sola máquina. De acuerdo con los experimentos, este principio puede producir aplicaciones mejores, de manera consistente, a iguales o menores costes. Está claro que 4 ojos ven mejor que 2.

Es muy importante, también, disponer de un buen estándar de codificación que defina la propiedad del código compartido, así como las reglas para escribir y documentar el mismo y la comunicación entre diferentes piezas desarrolladas por diferentes equipos. Los programadores deben seguirlas a rajatabla, de tal manera que el código en el sistema se vea como si hubiera estado escrito por una única persona.

La XP es un sistema que tiene ya diez años y no ha sido muy bien acogido por gerentes de empresas de desarrollo por considerar que no es un buen modelo y que es difícil de implementar. Nada más lejos de la realidad, aunque es posible que factores, como la excesiva implicación del cliente, representen dificultades a la hora de ponerlo en práctica. Todo es intentarlo y estar un poquito abierto de miras.

Si te pone el desarollo y quieres profundizar más en la programación extrema te recomiendo que leas este documento sobre el tema (en formato PDF y en castellano) y que te pases por Extreme Programming o por XProgramming.com.

1 comentario a “Programación extrema”