Metodologías para el desarrollo de software: Programación extrema (XP)

Esta es la única metodología que aprendí, re aprendí y no necesite modificar nada, de hecho cuando hay proyectos en parejas o grupos surte un efecto impresionante, es importante que no se utilice para proyectos "imposibles" ya que el equipo necesario para los proyectos debe ser cada vez mas grande para que siga siendo eficiente la XP(eXtreme Programing), para proyectos imposibles tengo mi incremental plagiado,  la mayoría de software empresarial si se puede crear con XP ya que estos proyectos requieren que muchos ojos estén sobre el código, el trabajo en parejas sobre la misma computadora consigue que siempre cada linea de código esté pensada y revisada dos veces evitando que los problemas de lógica o descuido atrasen el proyecto.

Según los autores que consulté a lo largo del tiempo la XP es el resultado de las mejores practicas de programación, algunas bases del sistema son:

• Simplicidad ya que cuando hacemos uso de la refactorización (mejorar la forma en que un método se ejecuta sin modificar su funcionalidad), nombramos las variables de forma explicita, métodos y clases con nombres mas explícitos, entre otras medidas nos ahorran mucho tiempo en codificación, un nombre largo puede ser considerado un estorbo por muchos programadores, pero cuando el tamaño del proyecto se vuelve complejo, el tiempo perdido en ver los comentarios será cada vez mayor, mejor no ahorrar letras sino ahorrarnos confusiones.

•  Comunicación es la segunda palabra clave, está muy relacionado con los comentarios pero también hay que recordar el auto comentado de código con los nombres de variables y métodos muy explícitos, ya que la funcionalidad de un método o clase debe ser explicada y cada vez que algo se modifique igualmente debe cambiar el comentario, recuerdo un ejemplo simpático donde un programador ponía la función de un método, declaraba dentro del comentario las horas que le había llevado hacerlo y un contador de la cantidad de veces que había dado ese método por finalizado, cada vez que alguien tocaba el método aumentaba el contador y le sumaba horas dándole cada vez mas valor a el método, esto es comunicación llevado a su mejor punto, valorar nuestro código con el tiempo que ha llevado crearlo y la cantidad de modificaciones que se le ha realizado a lo largo del tiempo nos ayuda a pensar antes de borrar o modificar alguna cosa.

•  Retroalimentación, el prototipo es algo que se debe hacer, pero en caso de que no se haga es importante que vayan siempre quedando sectores del proyecto ya terminados y se le muestre al cliente, siempre la retroalimentación en un proyecto es crucial sobre todas las cosas.

• Coraje, esto ya suena a discurso barato pero en mi experiencia tiene mucho sentido, algunas cosas pueden no estar bien en un primer momento pero con la excusa de que algo puede salir mal desperdiciamos mucho tiempo precioso, lo mejor es atrevernos al error y de una vez afrontar la tarea, un programador debe tener el coraje de trabajar en algo sin saber si funciona, probarlo múltiples veces y al final también debe tener el coraje de re hacer lo que sea necesario con tal de facilitar la comprensión del código y mejorar su funcionalidad, hay casos en que la gente se queda petrificada ante un problema que reescribiendo el código puede ser solucionado sin pensar mucho, claro está el coraje significa que llegados a un punto sin retorno el programador no va a sentirse avergonzado de pedir ayuda a otros, somos humanos y necesitamos tener este coraje para enfrentar las dificultades de todos los días ya no solo del código.

• Respeto, cuando nos damos cuenta que la humanidad está por encima del trabajo el respeto es el mayor valor necesario para trabajar dentro de este mundo globalizado, este respeto traspasa lo personal y nos obliga a evitar problemas, respetando la opinión de los demás mientras que las pruebas no revelen lo contrario.

Teniendo en claro los valores necesarios para trabajar bajo XP, vamos directo hacia el algoritmo de la metodología:

-Desarrollo incremental: que chistoso, si, el desarrollo incremental es solo un pequeño segmento de la XP y significa que tenemos la necesidad de trabajar el código continuamente, después de terminar una etapa de pruebas y análisis siempre será importante trabajar en las modificaciones al instante (FUÁ, CARACTER :D, ahora es motivador ese señor).

-Pruebas continuas unitarias automatizadas: No es una prueba que se repite, es que cada modulo del código debe ser probado por separado utilizando una herramienta creada para ese fin, en algunos casos se deben probar los métodos individualmente y linea por linea incluso, puede parecer tedioso pero las pruebas automatizadas son muy eficientes y pueden repetirse muchas veces mientras se modifica el código haciendo que exista una seguridad completa sobre el rendimiento y funcionalidad de cada fragmento.

-Programación en parejas: Cada computadora será ocupada por dos programadores que se turnarán, el código será discutido y revisado en tiempo real ahorrando muchas molestias aunque esto ya lo dije arriba.

-Integración del cliente en el proyecto: Es duro lograr que un cliente se involucre, pero utilizando reuniones mensuales o visitas semanales a la empresa es posible conseguir un cierto nivel de integración.

-Refactorización: consiste en reescribir el código sin modificar la funcionalidad, todos lo hemos hecho alguna vez pero no sabíamos que se llamaba así, ahora que saben lo que significa seguro que intentan hacerlo con todos los métodos de ahora en adelante.

-Responsabilidad compartida: los módulos en vez de repartirlos de forma arbitraria están al alcance de todos a través de un Git o repositorio de versiones compartido, posiblemente al inicio se trabaje por módulos y una vez el programa este en una fase temprana las parejas de desarrollo pasen entre módulos agregando cosas o modificando.

-Simplicidad en todo momento: el código en cada revisión debe permanecer simple, si tiene todo el equipo de desarrollo que turnarse a refactorizar el mismo método con tal de mantenerlo simple, se hará sin ningún problema, cuando un código se vuelve imposible de entender, el proyecto entero cae en riesgo de ser abandonado y como desarrolladores debemos trabajar para que esto nunca suceda.

Esta metodología me encanta por que tiene las mismas leyes que un pequeño escrito llamado el zen de python "simple es mejor que complejo, complejo es mejor que complicado, los casos especiales no son lo suficientemente especiales para romper las reglas, de cara a la ambigüedad rechaza la tentación de adivinar", en palabras claras todo debería ser simple o complejo pero nunca hay que permitir que se complique, no debemos saltarnos las reglas y sobre todo ante la duda lo mejor es preguntarle a otros para evitar catástrofes , en todos los lenguajes de programación deberíamos aplicar esta importante lección de nuestro benevolente dictador de por vida Guido van Rossum creador de python.