Extreme Programming ( Programación Extrema , XP ) es una de las metodologías ágiles de desarrollo de software . Los autores de la metodología son Kent Beck , Ward Cunningham , Martin Fowler y otros.
El nombre de la metodología proviene de la idea de aplicar prácticas y métodos tradicionales útiles de desarrollo de software, llevándolos a un nuevo nivel "extremo". Así, por ejemplo, la práctica de realizar revisión de código , que consiste en comprobar por un programador el código escrito por otro programador, en la versión "extrema" es "programación en pareja", cuando un programador está escribiendo código, y su compañero en el Al mismo tiempo, está revisando continuamente qué código está escrito.
La metodología fue desarrollada por Kent Beck durante su trabajo en el proyecto de nómina Chrysler Comprehensive Compensation System (C3) . Beck se convirtió en el especialista principal del proyecto en marzo de 1996. Comenzó a mejorar la metodología de desarrollo utilizada en el proyecto y escribió un libro al respecto, Explicación de la programación extrema (publicado en octubre de 1999). [1] El proyecto se cerró en febrero de 2000.
Las doce técnicas básicas de Programación Extrema (según la primera edición de Programación Extrema explicada ) se pueden agrupar en cuatro grupos:
XP implica escribir pruebas automatizadas (código escrito específicamente para probar la lógica de otro código). Se presta especial atención a dos tipos de pruebas:
Un desarrollador no puede estar seguro de la corrección del código que escribe hasta que funcionen absolutamente todas las pruebas unitarias del sistema que desarrolla. Las pruebas unitarias (unit tests) permiten a los desarrolladores asegurarse de que cada uno de ellos individualmente funcione correctamente. También ayudan a otros desarrolladores a comprender por qué se necesita una pieza de código en particular y cómo funciona: en el curso del estudio del código de prueba, la lógica del código bajo prueba se vuelve clara, ya que está claro cómo debe usarse. Las pruebas unitarias también permiten al desarrollador refactorizar sin ningún temor .
Las pruebas funcionales están diseñadas para probar el funcionamiento de la lógica formada por la interacción de varias partes (a menudo de un tamaño bastante impresionante). Son menos detallados que las pruebas unitarias, pero cubren mucho más, es decir, las pruebas que, cuando se ejecutan, afectan una mayor cantidad de código, obviamente tienen una mayor probabilidad de detectar cualquier comportamiento incorrecto. Por esta razón, en la programación industrial, escribir pruebas funcionales a menudo tiene prioridad sobre escribir pruebas unitarias.
Para XP, un enfoque llamado TDD (del inglés test-driven development - desarrollo a través de pruebas ) es una prioridad más alta. De acuerdo con este enfoque, primero se escribe una prueba que inicialmente falla (ya que la lógica que debe verificar simplemente no existe todavía), luego se implementa la lógica necesaria para que la prueba pase. TDD, en cierto sentido, le permite escribir código que es más conveniente de usar, porque al escribir una prueba, cuando aún no hay lógica, es más fácil ocuparse de la conveniencia del futuro sistema.
El objetivo principal del juego de planificación es formar rápidamente un plan de trabajo aproximado y actualizarlo constantemente a medida que las condiciones de la tarea se vuelven más claras. Los artefactos del juego de planificación son un conjunto de tarjetas de papel que contienen los deseos del cliente (historias de clientes) y un plan de trabajo aproximado para el lanzamiento de la siguiente o más pequeñas versiones del producto. El factor crítico que hace que este estilo de planificación sea efectivo es que en este caso el cliente es el responsable de tomar las decisiones comerciales y el equipo de desarrollo es responsable de tomar las decisiones técnicas. Si no se sigue esta regla, todo el proceso se desmorona.
El "cliente" en XP no es quien paga las facturas, sino el usuario final del producto de software. XP afirma que el cliente debe estar en contacto todo el tiempo y disponible para preguntas.
La programación en pares asume que todo el código es creado por pares de programadores que trabajan en la misma computadora. Uno de ellos trabaja directamente con el texto del programa, el otro mira su trabajo y sigue el panorama general de lo que está sucediendo. Si es necesario, el teclado se transfiere libremente de uno a otro. Mientras se trabaja en un proyecto, los pares no son fijos: se recomienda mezclarlos para que cada programador del equipo tenga una buena idea de todo el sistema. Por lo tanto, la programación en pareja mejora la interacción dentro del equipo.
Si integra el sistema en desarrollo con la suficiente frecuencia, puede evitar la mayoría de los problemas asociados con él. En los métodos tradicionales, la integración, por regla general, se realiza al final del trabajo en el producto, cuando se considera que todos los componentes del sistema que se está desarrollando están completamente listos. En XP, la integración del código de todo el sistema se realiza varias veces al día, después de que los desarrolladores se hayan asegurado de que todas las pruebas unitarias funcionen correctamente.
La refactorización es una técnica para mejorar el código sin cambiar su funcionalidad. XP implica que una vez que se escribe el código, es casi seguro que se rehará muchas veces durante el transcurso de un proyecto. Los desarrolladores de XP están reelaborando despiadadamente el código escrito previamente para mejorarlo. Este proceso se llama refactorización. La falta de cobertura de pruebas provoca el rechazo a la refactorización por temor a romper el sistema, lo que conduce a la degradación paulatina del código.
Las versiones (lanzamientos) del producto deben entrar en producción con la mayor frecuencia posible. El trabajo en cada versión debe tomar el menor tiempo posible. Al mismo tiempo, cada versión debe ser lo suficientemente significativa en términos de utilidad para el negocio.
Cuanto antes se lance la primera versión funcional del producto, antes comenzará el cliente a recibir beneficios adicionales debido a ello. Recuerda que el dinero ganado hoy vale más que el dinero ganado mañana. Cuanto antes el cliente comience a usar el producto, antes los desarrolladores recibirán información de él sobre lo que cumple con los requisitos del cliente. Esta información puede ser extremadamente útil al planificar su próximo lanzamiento.
XP proviene del hecho de que, en el curso del trabajo, las condiciones del problema pueden cambiar repetidamente, lo que significa que el producto que se está desarrollando no debe diseñarse de antemano por completo y por completo. Intentar diseñar el sistema en detalle al comienzo del trabajo es una pérdida de tiempo. XP sugiere que el diseño es un proceso tan importante que debe realizarse continuamente durante la vida del proyecto. El diseño debe llevarse a cabo en pequeños pasos, teniendo en cuenta los requisitos en constante cambio. En cada momento, debe tratar de usar el diseño más simple que se adapte al problema actual y cambiarlo a medida que cambien las condiciones del problema.
Kent Beck y Martin Fowler [2] proponen describir el "diseño simple" como el cumplimiento de los siguientes cuatro criterios:
Robert Martin está de acuerdo [3] con estas reglas, pero en su trabajo anterior [4] también sugiere describir el "diseño simple" con los siguientes tres principios:
La arquitectura es una representación de los componentes de un sistema y sus relaciones entre sí. Los desarrolladores deben analizar la arquitectura del software para comprender en qué parte del sistema necesitan agregar una nueva funcionalidad y con qué interactuará el nuevo componente.
La metáfora del sistema es análoga a lo que la mayoría de las técnicas llaman arquitectura. La metáfora del sistema le da al equipo una idea de cómo funciona el sistema actualmente, dónde se agregan nuevos componentes y qué forma deben tomar.
Elegir una buena metáfora facilita que el equipo de desarrollo entienda cómo funciona el sistema. A veces esto no es fácil de hacer.
En este punto, Bob Martin ha reconocido que la metáfora del sistema está desactualizada y debería ser reemplazada por Domain Driven Design .
Todos los miembros del equipo en el curso del trabajo deben cumplir con los requisitos de los estándares de codificación comunes. De este modo:
Si el equipo no usa estándares de codificación uniformes, se vuelve más difícil para los desarrolladores refactorizar; al cambiar de pareja en parejas, hay más dificultades; en general, el progreso del proyecto es difícil. En el marco de XP, es necesario dificultar la comprensión de quién es el autor de este o aquel código: todo el equipo trabaja de manera unificada, como una sola persona. El equipo debe formar un conjunto de reglas y luego cada miembro del equipo debe seguir estas reglas mientras escribe el código. La lista de normas no debe ser exhaustiva ni demasiado voluminosa. La tarea es formular pautas generales que harán que el código sea comprensible para cada uno de los miembros del equipo. El estándar de codificación debe ser simple al principio, luego puede volverse más complejo gradualmente a medida que el equipo de desarrollo adquiere experiencia. No es necesario dedicar demasiado tiempo a la redacción previa de una norma.
La propiedad colectiva significa que cada miembro del equipo es responsable de todo el código fuente . Por lo tanto, todos tienen derecho a realizar cambios en cualquier parte del programa. La programación en pares apoya esta práctica: trabajando en diferentes pares, todos los programadores se familiarizan con todas las partes del código del sistema. Un beneficio importante de la propiedad colectiva del código es que acelera el proceso de desarrollo, ya que cuando ocurre un error, cualquier programador puede corregirlo.
El derecho de cada programador a cambiar el código corre el riesgo de que los programadores introduzcan errores que creen que saben lo que están haciendo pero no consideran algunas dependencias. Los programadores extremos creen que las pruebas unitarias bien definidas resuelven este problema: si las dependencias no revisadas generan errores, la próxima ejecución de las pruebas unitarias fallará y revelará el problema.
| Desarrollo de software | |
|---|---|
| Proceso | |
Conceptos de alto nivel | |
| Direcciones |
|
| Metodologías de desarrollo | |
| Modelos |
|
Figuras notables |
|