Menu Close

Programación Extrema – Mini-introducción

Esta es una pequeña introducción en Español acerca de Programación Extrema (Extreme Programming).
Describe a grandes rasgos la dinámica de un proyecto manejado con este método.

Describe los pasos en general de un proyecto XP, y algunas de sus ventajas y desventajas.

La disciplina de desarrollo de software es todavía jóven. En una ciencia
joven, es típico que las nociones de lo que es correcto e incorrecto cambien
más seguido que en una ciencia más madura.

Asímismo, la orientación a objetos y el Internet ha traído consigo mismo
nuevas maneras de escribir software, no sólo en lenguajes y técnicas, sino
también en el lado humano y organizacional.

El estilo para desarrollar sistemas complejos también está cambiando. El
método de cascada (waterfall), donde los requerimientos se fijan antes de
escribir una sóla línea de código está siendo reemplazado por variaciones de un
metodo llamado “Extreme Programming”, o programación extrema.

A diferencia del método de cascada, la metodología de programación extrema
es más orgánica.

Los pasos de un projecto XP

En un equipo que utiliza programación extrema o alguna de sus variantes, las
siguientes cosas tienden a ocurrir:

Cuéntame una de Vaqueros

Desarrolladores de sistemas con experiencia amplia en desarrollar sistemas
basados en objetos tienen una o dos juntas donde le piden a los usuarios que
“les cuenten una historia”. El usuario explica como funcionan los procesos
existentes. Dentro de ésta conversación, los casos de uso (“use cases”) se van
afinando.

Escribe un Poco de Código, Prueba un poco

En una manera muy diferente al método de cascada, el código comienza a ser
escrito desde el momento en el cual la primera “historia” (caso de uso) está
escrita. Pero en vez de comenzar con código de implementación, el programador
comienza con un código de prueba de unidad. Después el programador escribe
el código más sencillo que satisface la prueba.

Probando… Probando…

El escribir las pruebas antes del código tiene las siguientes ventajas:

  1. Ayuda automáticamente a ser más claro sobre el diseño de la futura
    clase que va a satisfacer la prueba, ya que obliga al programador a pensar en
    la interface y los resultados esperados primero, independientemente del
    ambiente externo a la función o clase en cuestión.
  2. Dada la típica independencia funcional de la clase de prueba, le
    proporciona a los programadores un ejemplo del uso esperado de la clase, así
    como documentación relativamente simple del diseño de la clase que siempre se
    mantendrá actualizada (porque si se cambia la interface o las reglas, la prueba
    se va a romper, ya sea porque no compila o porque falla al no encontrar los
    resultados esperados, lo cual obliga a cambiar o la prueba o el código).
  3. Con el tiempo, la organización cuenta con una lista de pruebas que
    se pueden aplicar para verificar la validez de código nuevo. Dichas pruebas se
    pueden automatizar y preparar para que corran de noche o como parte del proceso
    de verificación antes de enviar a control de calidad (e instalar “en
    vivo”).

Es por esto que los programadores de XP siempre dicen “No has acabado hasta
que todas las pruebas corran”

Afinando la Puntería

Una vez que hay un cuerpo de código algo considerable y algo de interface de
usuario, típicamente el software se prueba y se muestra a los usuarios, quienes
proporcionan sus impresiones. A esto se le llama afinar la puntería, ya que
típicamente en este momento los usuarios nos explican que eso no es exactamente
lo que querían. Es útil, ya que le permite a los programadores darse cuenta de
los problemas de utilización de la interfaz del usuario antes de terminar el
sistema, cuando el código que hay que reemplazar todavía es lo suficientemente
pequeño.

Refactorizar Sin Piedad

Otra faceta de el desarrollo en XP es el énfasis en lo que llaman
“Refactorización sin piedad”. Los desarrolladores constantemente revisan los
sistemas existentes y mejoran las clases y las interfases. Como se cuenta con
pruebas de unidad, se puede mejorar el código con un poco más de libertad.

Ventajas y Problemas del Método XP

La calidad de los sistemas basados en XP tiende a ser un poco mejor, en
particular si se utilizan patrones de diseño.

Obviamente, ningún método es perfecto. El problema que más se menciona con
los proyectos de XP es que es difícil predecir costo y tiempo de desarrollo.

Por otra parte, el desarrollo de software con XP es más flexible, y como el
sistema comienza a crecer orgánicamente, es más sencillo remover funciones para
cumplir con el tiempo de desarrollo sin poner en riesgo el resto del sistema.

Otro problema del método XP es que, si se utilizan diagramas UML, éstos
tienden a estar poco actualizados, debido a la constante refactorización.

.