Programación extrema

Los defensores de XP argumentan que el único producto verdaderamente importante del proceso de desarrollo de sistemas es el código: las instrucciones de software que una computadora puede interpretar. Sin código, no hay un producto funcional.

La codificación puede utilizarse para encontrar la solución más adecuada. También puede ayudar a comunicar ideas sobre problemas de programación. Un programador que se enfrenta a un problema complejo o que tiene dificultades para explicar la solución a otros programadores, puede codificarla de forma simplificada y usar el código para ilustrar su idea. Según quienes defienden esta postura, el código siempre es claro y conciso, y no admite más de una interpretación. Otros programadores pueden aportar comentarios sobre este código codificando también sus propias ideas.

Las pruebas son fundamentales para la programación extrema. ^{[ 10 ]} El enfoque de la programación extrema es que si unas pocas pruebas pueden eliminar algunos defectos, muchas pruebas pueden eliminar muchos más.

• Las pruebas unitarias determinan si una función determinada funciona según lo previsto. Los programadores escriben tantas pruebas automatizadas como se les ocurran que puedan provocar fallos en el código; si todas las pruebas se ejecutan correctamente, la codificación está completa. Cada fragmento de código escrito se prueba antes de pasar a la siguiente función.
• Las pruebas de aceptación verifican que los requisitos, tal como los entienden los programadores, satisfacen las necesidades reales del cliente.

Inicialmente, se fomentaba la realización de pruebas de integración de todo el sistema como una actividad diaria al final del día para la detección temprana de interfaces incompatibles. Sin embargo, estas pruebas se han reducido a una frecuencia semanal o incluso menor, dependiendo de la estabilidad de las interfaces generales del sistema. ^{[ 11 ]}

Los programadores deben escuchar las necesidades de los clientes y comprender la lógica de negocio requerida. Deben entender estas necesidades lo suficientemente bien como para brindar al cliente información sobre los aspectos técnicos de la posible solución del problema, así como sobre si este puede resolverse dentro de las limitaciones establecidas. La comunicación entre el cliente y el programador se aborda con mayor profundidad en el juego de planificación .

Desde el punto de vista de la simplicidad, se podría decir que el desarrollo de un sistema no requiere más que codificación, pruebas y escucha. Si estas actividades se realizan correctamente, el resultado debería ser siempre un sistema funcional. En la práctica, esto no siempre funciona. Se puede avanzar mucho sin un diseño previo, pero tarde o temprano se producirá un estancamiento. El sistema se vuelve demasiado complejo y las dependencias internas dejan de ser claras. Esto se puede evitar creando una estructura de diseño que organice la lógica del sistema. Un buen diseño evitará muchas dependencias internas; esto significa que modificar una parte del sistema no afectará a las demás.

La creación de sistemas de software requiere comunicar los requisitos del sistema a los desarrolladores. En las metodologías formales de desarrollo de software, esta tarea se realiza mediante documentación. Las técnicas de programación extrema pueden considerarse métodos para generar y difundir rápidamente el conocimiento institucional entre los miembros de un equipo de desarrollo. El objetivo es brindar a todos los desarrolladores una visión compartida del sistema que coincida con la de los usuarios. Para ello, la programación extrema favorece los diseños sencillos, las metáforas comunes, la colaboración entre usuarios y programadores, la comunicación verbal frecuente y la retroalimentación.

La programación extrema fomenta comenzar con la solución más simple. La funcionalidad adicional se puede agregar posteriormente. La diferencia entre este enfoque y los métodos de desarrollo de sistemas más convencionales radica en el enfoque en diseñar y codificar para las necesidades de hoy en lugar de las de mañana, la próxima semana o el próximo mes. Esto a veces se resume como el enfoque " No lo vas a necesitar " (YAGNI). ^{[ 12 ]} Los defensores de XP reconocen la desventaja de que esto a veces puede implicar más esfuerzo mañana para cambiar el sistema; afirman que esto se compensa con creces por la ventaja de no invertir en posibles requisitos futuros que podrían cambiar antes de ser relevantes. Codificar y diseñar para requisitos futuros inciertos implica el riesgo de gastar recursos en algo que podría no ser necesario, mientras que tal vez se retrasen características cruciales. En relación con el valor de la "comunicación", la simplicidad en el diseño y la codificación debería mejorar la calidad de la comunicación. Un diseño simple con un código muy simple podría ser fácilmente comprendido por la mayoría de los programadores del equipo.

En la programación extrema, la retroalimentación se relaciona con diferentes dimensiones del desarrollo del sistema:

• Retroalimentación del sistema: al escribir pruebas unitarias ^{[ 5 ]} o ejecutar pruebas de integración periódicas, los programadores obtienen retroalimentación directa del estado del sistema después de implementar cambios.
• Comentarios del cliente: Las pruebas funcionales (también conocidas como pruebas de aceptación ) son elaboradas por el cliente y los evaluadores. De esta manera, recibirán información concreta sobre el estado actual de su sistema. Esta revisión se realiza cada dos o tres semanas para que el cliente pueda orientar fácilmente el desarrollo.
• Comentarios del equipo: Cuando los clientes plantean nuevos requisitos durante la fase de planificación, el equipo proporciona directamente una estimación del tiempo que llevará implementarlos.

La retroalimentación está estrechamente relacionada con la comunicación y la simplicidad. Los fallos del sistema se comunican fácilmente mediante una prueba unitaria que demuestre que una parte específica del código fallará. La retroalimentación directa del sistema indica a los programadores que deben recodificar esa parte. Un cliente puede probar el sistema periódicamente según los requisitos funcionales, conocidos como historias de usuario . ^{[ 5 ]} Citando a Kent Beck : «El optimismo es un riesgo laboral de la programación. La retroalimentación es el tratamiento». ^{[ 13 ]}

Varias prácticas encarnan el coraje. Una es el mandamiento de diseñar y programar siempre para hoy y no para mañana. Esto es un esfuerzo para evitar estancarse en el diseño y requerir mucho esfuerzo para implementar cualquier otra cosa. El coraje permite a los desarrolladores sentirse cómodos refactorizando su código cuando sea necesario. ^{[ 5 ]} Esto significa revisar el sistema existente y modificarlo para que los cambios futuros se puedan implementar más fácilmente. Otro ejemplo de coraje es saber cuándo desechar código: coraje para eliminar código fuente obsoleto, sin importar cuánto esfuerzo se haya invertido en crearlo. Además, el coraje significa persistencia: un programador puede estar atascado en un problema complejo durante todo un día, luego resolverlo rápidamente al día siguiente, pero solo si es persistente.

El valor del respeto abarca tanto el respeto por los demás como el respeto por uno mismo. Los programadores nunca deben realizar cambios que impidan la compilación, que provoquen fallos en las pruebas unitarias existentes o que retrasen el trabajo de sus compañeros. Los miembros respetan su propio trabajo escribiendo código de alta calidad y buscando el mejor diseño para la solución en cuestión mediante la refactorización.

La adopción de los cuatro valores mencionados anteriormente genera respeto entre los miembros del equipo. Nadie debe sentirse menospreciado ni ignorado. Esto garantiza una alta motivación y fomenta la lealtad hacia el equipo y el objetivo del proyecto. Este valor depende de los demás y está orientado al trabajo en equipo.

La programación extrema considera que la retroalimentación es más útil si se realiza con frecuencia y rapidez. Enfatiza que un retraso mínimo entre una acción y su retroalimentación es fundamental para el aprendizaje y la implementación de cambios. A diferencia de los métodos tradicionales de desarrollo de sistemas, el contacto con el cliente se produce en iteraciones más frecuentes. El cliente tiene una visión clara del sistema en desarrollo y puede brindar retroalimentación y orientar el desarrollo según sea necesario. Con la retroalimentación frecuente del cliente, un error de diseño por parte del desarrollador se detectará y corregirá rápidamente, antes de que este dedique mucho tiempo a su implementación.

Las pruebas unitarias contribuyen al principio de retroalimentación rápida. Al escribir código, ejecutar las pruebas unitarias proporciona información directa sobre cómo reacciona el sistema a los cambios realizados. Esto incluye ejecutar no solo las pruebas unitarias que prueban el código del desarrollador, sino también todas las pruebas unitarias de todo el software, mediante un proceso automatizado que se puede iniciar con un solo comando. De esta forma, si los cambios del desarrollador provocan un fallo en alguna otra parte del sistema que desconoce, el conjunto automatizado de pruebas unitarias revelará el fallo de inmediato, alertando al desarrollador de la incompatibilidad de su cambio con otras partes del sistema y de la necesidad de eliminarlo o modificarlo. Con las prácticas de desarrollo tradicionales, la ausencia de un conjunto automatizado e integral de pruebas unitarias implicaba que un cambio de código, considerado inofensivo por el desarrollador, se mantendría sin cambios, apareciendo solo durante las pruebas de integración o, peor aún, solo en producción; y determinar qué cambio de código causó el problema, entre todos los cambios realizados por todos los desarrolladores durante las semanas o incluso meses previos a las pruebas de integración, era una tarea titánica.

Se trata de abordar cada problema como si su solución fuera "extremadamente simple". Los métodos tradicionales de desarrollo de sistemas recomiendan planificar a futuro y programar para la reutilización. La programación extrema rechaza estas ideas.

Los defensores de la programación extrema afirman que realizar grandes cambios de golpe no funciona. La programación extrema aplica cambios incrementales: por ejemplo, un sistema podría tener pequeñas actualizaciones cada tres semanas. Al realizar muchos pasos pequeños, el cliente tiene mayor control sobre el proceso de desarrollo y el sistema que se está desarrollando.

El principio de aceptar el cambio consiste en no oponerse a él, sino acogerlo. Por ejemplo, si en una de las reuniones iterativas se observa que los requisitos del cliente han cambiado drásticamente, los programadores deben aceptarlo y planificar los nuevos requisitos para la siguiente iteración.