Programación extrema

Na Galipedia, a Wikipedia en galego.
Saltar ata a navegación Saltar á busca

A programación extrema, ou XP (do inglés extreme programming), é unha metodoloxía áxil de enxeñería de software chamada así porque leva ao seu extremo algunhas prácticas de desenvolvemento como a cooperación, a testaxe ou a presentación de resultados.

Historia[editar | editar a fonte]

A programación extrema foi posta en práctica inicialmente en 1996 por Kent Beck, autor que recolleu a súa experiencia no primeiro libro sobre esta metodoloxía, Extreme Programming Explained: Embrace Change (1999), pero ten habido distintos autores que, ao longo de distintas publicacións e manuais, modificaron e ampliaron os principios recollidos por Beck naquela altura.

Principios[editar | editar a fonte]

Como calquera metodoloxía áxil, a programación extrema ten uns principios de partida a medio camiño entre a eficiencia produtiva e o enfoque moral. Por iso comezou Beck (1999) polo establecemento duns guieiros de comportamento para os equipos de desenvolvemento e os proxectos. No caso da programación extrema, estes guieiros ou principios foron orixinalmente comunicación, simplicidade, retroalimentación e valentía, e posteriormente (2004) o propio Beck engadiu un quinto principio, o de respecto.

Características[editar | editar a fonte]

As características fundamentais do método son:

  • Desenvolvemento iterativo e incremental: pequenas melloras, unhas tras doutras.
  • Probas unitarias continuas, frecuentemente repetidas e automatizadas, incluíndo probas de regresión. Aconséllase escribi-lo código da proba antes da codificación. Por exemplo, JUnit.
  • Programación por parellas: recoméndase que as tarefas de desenvolvemento se leven a cabo por dúas persoas nun mesmo posto. Suponse que a maior calidade do código escrito desta maneira -o código é revisado e discutido mentres se escribe- é máis importante cá posible perda de produtividade inmediata.
  • Frecuente interacción do equipo de programación co cliente ou usuario. Recoméndase que un representante do cliente traballe xunto ó equipo de desenvolvemento.
  • Corrección de tódolos erros antes de engadir nova funcionalidade. Facer entregas frecuentes.
  • Refactorización do código, é dicir, reescribir certas partes do código para aumenta-la súa lexibilidade e mantenibilidade pero sen modifica-lo seu comportamento. As probas han de garantir que na refactorización non se introduciu ningún fallo.
  • Propiedade do código compartida: en vez de dividi-la responsabilidade no desenvolvemento de cada módulo en grupos de traballo distintos, este método promove que todo o persoal poida corrixir e estender calquera parte do proxecto. As frecuentes probas de regresión garanten que os posibles erros serán detectados.