Prácticas de programación extrema

La programación en parejas es un método de programación en el que dos personas trabajan juntas en una misma tarea. Un programador controla la estación de trabajo y se centra principalmente en los detalles de la codificación. El otro programador se enfoca en el panorama general y revisa continuamente el código que produce el primero. Los programadores intercambian roles cada pocos minutos o horas.

Las parejas no son fijas; los programadores cambian de compañero con frecuencia, de modo que todos sepan qué hace cada uno y se familiaricen con el sistema en su conjunto, incluso con las partes que escapan a su dominio. De esta forma, la programación en parejas también puede mejorar la comunicación dentro del equipo. (Esto se relaciona directamente con el concepto de propiedad colectiva).

El principal proceso de planificación dentro de la programación extrema se llama Juego de Planificación. El juego es una reunión que se lleva a cabo una vez por iteración, generalmente una vez por semana. El proceso de planificación se divide en dos partes:

• Planificación de lanzamientos : Se centra en determinar qué requisitos se incluyen en cada lanzamiento a corto plazo y cuándo deben entregarse. Tanto los clientes como los desarrolladores participan en este proceso. La planificación de lanzamientos consta de tres fases:
  • Fase de exploración: En esta fase, el cliente proporcionará una lista reducida de requisitos de alto valor para el sistema. Estos se plasmarán por escrito en tarjetas de historias de usuario .
  • Fase de compromiso: Durante la fase de compromiso, tanto la empresa como los desarrolladores se comprometerán con la funcionalidad que se incluirá y la fecha de la próxima versión.
  • Fase de dirección: En la fase de dirección se puede ajustar el plan, añadir nuevos requisitos y/o modificar o eliminar los requisitos existentes.
• Planificación de iteraciones : Esta planificación define las actividades y tareas de los desarrolladores. En este proceso, el cliente no participa. La planificación de iteraciones también consta de tres fases:
  • Fase de exploración: En esta fase, el requisito se traducirá en diferentes tareas. Las tareas se registran en fichas de tareas.
  • Fase de compromiso: Se asignarán las tareas a los programadores y se estimará el tiempo necesario para completarlas.
  • Fase de dirección: Se realizan las tareas y el resultado final se ajusta a la historia de usuario original.

El propósito del Juego de Planificación es guiar el producto hacia su entrega. En lugar de predecir las fechas exactas en que se necesitarán y producirán los entregables, lo cual es difícil, busca "dirigir el proyecto" hacia la entrega mediante un enfoque directo. ^{[ 2 ]} El enfoque del Juego de Planificación se utiliza en marcos de desarrollo que van más allá de los sistemas de software. Por ejemplo, lo utilizan equipos en el contexto de la agilidad empresarial . ^{[ 3 ]}

Las pruebas unitarias son pruebas automatizadas que verifican la funcionalidad de partes del código (por ejemplo, clases, métodos). En XP, las pruebas unitarias se escriben antes de codificar el código final. Este enfoque busca estimular al programador a pensar en las condiciones bajo las cuales su código podría fallar. XP establece que el programador ha terminado con una parte del código cuando no puede encontrar ninguna otra condición bajo la cual el código pueda fallar.

El desarrollo guiado por pruebas (TDD) se lleva a cabo mediante un ciclo rápido que recorre los siguientes pasos, cada uno de los cuales dura como máximo unos minutos, preferiblemente mucho menos. Dado que cada historia de usuario suele requerir entre uno y dos días de trabajo, será necesario un gran número de ciclos de este tipo por historia.

• Escribir pruebas unitarias : Los programadores escriben una prueba mínima que debería fallar porque la funcionalidad no se ha implementado completamente en el código de producción.
• Observa cómo falla la nueva prueba: Los programadores verifican que, efectivamente, la prueba falla. Aunque pueda parecer una pérdida de tiempo, este paso es fundamental, ya que confirma que tu suposición sobre el estado del código de producción es correcta. Si la prueba no falla, los programadores deben determinar si existe un error en el código de prueba o si el código de producción sí admite la funcionalidad descrita por la nueva prueba.
• Escribir código: Los programadores escriben el código de producción justo y necesario para que la nueva prueba pase.
• Ejecutar prueba: Las pruebas unitarias se ejecutan para verificar que el nuevo código de producción pasa la nueva prueba y que ninguna otra prueba está fallando.
• Refactorizar : Eliminar cualquier problema de diseño del código , tanto del código de producción como del código de prueba.

Para una versión más intensa del proceso anterior, consulte las Tres reglas de TDD del tío Bob. ^{[ 4 ]}

En XP, el "cliente" no es quien paga la factura, sino quien realmente usa el sistema. XP establece que el cliente debe estar siempre disponible y responder preguntas. Por ejemplo, el equipo que desarrolla un sistema de administración financiera debe incluir un administrador financiero. El equipo debe contar con todas las habilidades necesarias para entregar el producto de software.

El equipo de desarrollo siempre debe trabajar con la última versión del software. Dado que los distintos miembros del equipo pueden tener versiones guardadas localmente con diversas modificaciones y mejoras, deberían intentar subir su versión actual al repositorio de código cada pocas horas o cuando se produzca un fallo importante. La integración continua evitará retrasos posteriores en el ciclo del proyecto, causados ​​por problemas de integración.

Dado que la filosofía XP aboga por programar solo lo necesario en el momento y su implementación de la forma más sencilla posible, en ocasiones esto puede provocar que el sistema se bloquee. Uno de los síntomas es la necesidad de un mantenimiento dual (o múltiple): los cambios funcionales requieren modificaciones en varias copias del mismo código (o de uno similar). Otro síntoma es que los cambios en una parte del código afectan a muchas otras. La filosofía XP indica que, cuando esto ocurre, el sistema está indicando la necesidad de refactorizar el código modificando su arquitectura, haciéndola más simple y genérica.

La entrega del software se realiza mediante lanzamientos frecuentes de funcionalidades reales, lo que genera valor concreto. Estos lanzamientos pequeños ayudan al cliente a tener confianza en el progreso del proyecto. Esto contribuye a mantener la coherencia del equipo, ya que el cliente puede aportar sugerencias basadas en su experiencia real.

Un estándar de codificación es un conjunto de reglas acordadas que todo el equipo de desarrollo se compromete a seguir durante todo el proyecto. El estándar especifica un estilo y formato consistentes para el código fuente , dentro del lenguaje de programación elegido , así como diversas construcciones y patrones de programación que deben evitarse para reducir la probabilidad de defectos. ^{[ 5 ]} El estándar de codificación puede ser una convención estándar especificada por el proveedor del lenguaje (por ejemplo, las Convenciones de Código para el Lenguaje de Programación Java, recomendadas por Sun) o definida a medida por el equipo de desarrollo.

Los defensores de la Programación Extrema abogan por un código que se autodocumente en la mayor medida posible. Esto reduce la necesidad de comentarios en el código , que pueden quedar desincronizados con el propio código. ^{[ 6 ]}

Los programadores deben adoptar un enfoque de «lo simple es mejor» en el diseño de software. Cada vez que se escribe un nuevo fragmento de código, el autor debe preguntarse: «¿Existe una forma más sencilla de implementar la misma funcionalidad?». Si la respuesta es afirmativa, se debe optar por la opción más sencilla. La refactorización también debe utilizarse para simplificar el código complejo.

La metáfora del sistema es una historia que todos —clientes, programadores y gerentes— pueden contar sobre cómo funciona el sistema. Es un concepto de nomenclatura para clases y métodos que debería facilitar que un miembro del equipo deduzca la funcionalidad de una clase o método en particular, solo con su nombre. Por ejemplo, un sistema de biblioteca puede crear un objeto loan_records(class)para borrowers(class), y si el objeto se vence, puede realizar una operación make_overdue en un catalogue(class). Para cada clase u operación, la funcionalidad es obvia para todo el equipo.

La idea es que los programadores o desarrolladores de software no trabajen más de 40 horas semanales, y si hay horas extras una semana, la siguiente no debería incluir más. Dado que los ciclos de desarrollo son cortos, con integración continua, y los ciclos completos de desarrollo (lanzamiento) son más frecuentes, los proyectos en XP no siguen el típico ritmo de trabajo intensivo que requieren otros proyectos (que exigen horas extras).

Además, este concepto incluye la idea de que las personas rinden mejor y son más creativas si están bien descansadas.

Un factor clave para lograr un ritmo de trabajo sostenible es la fusión frecuente de código y un código de alta calidad, siempre ejecutable y sometido a pruebas exhaustivas. La constante refactorización fomenta la concentración y la atención de los miembros del equipo. La intensa colaboración dentro del equipo genera la necesidad de recargar energías durante los fines de semana.

El código y los entornos, que han sido sometidos a pruebas exhaustivas, se integran de forma continua y se implementan con frecuencia, también minimizan la frecuencia de problemas e interrupciones inesperadas en la producción, así como el trabajo nocturno y de fin de semana que se requiere en consecuencia.