Sentiamo spesso parlare di Extreme Programming nel mondo della programmazione: vediamo insieme di cosa si tratta, dove nasce e perché, e quali sono le sue caratteristiche principali. Partiamo subito col dire che Extreme Programming (abbreviato in XP) vuol dire semplicemente – dall’ inglese – programmazione estrema ed è una metodologia di sviluppo del software che mette in risalto la scrittura del codice.
Sviluppato da Kent Beck (firmatario del manifesto Agile nonché coideatore del TDD) con l’ausilio di Ward Cunningham e Ron Jeffries, l’extreme programming incontra un certo tipo di successo tra gli anni ’90 e i primi 2000. Mantra di questa metodologia di sviluppo software della famiglia Agile è: divieto assoluto per i programmatori di scrivere codice non necessario.
Pratiche e Regole dell’Extreme Programming
Attenzione perché sono ben 12 le regole e le pratiche di sviluppo software che provengono da XP:
- Pair Programming,
- Planning Game
- Test Driven Development
- Whole Team
- Refactoring
- Continuous Integration
- Small Release
- Coding Standard
- Collective Ownership
- Simple Design
- System Metaphor
- Sustainable Pace
Modelli Extreme Programming
Un altro esponente di spicco, nonché autore di molti libri su XP, James Donovan Wells individuò una serie di modelli utili per interpretare i processi, 4 per l’esattezza:
- comunicazione (tutti possono e devono parlare con tutti, persino “l’ultimo dei programmatori” ha diritto di parola con il cliente);
- semplicità (dogma assoluto: descrizione formale del progetto il più semplice e chiara possibile);
- verifica (si parte subito a colpi di codice, fin dal primo giorno in cui parte il progetto);
- coraggio (il prima possibile dev’essere dato in uso il sistema dunque si implementano i cambiamenti richiesti man mano).
Sempre James Donovan Wells sottolinea 4 fasi di progetto, ognuna con regole proprie:
- pianificazione
- progettazione
- sviluppo
- collaudo
I 5 valori fondamentali di XP
Valori che prendono per ovvi motivi spunto dalle 4 modalità di interpretare i processi che abbiamo visto poc’anzi:
- Comunicazione – I membri di un team di sviluppo devono comunicare costantemente fra di loro così come con il cliente
- Semplicità – I processi di sviluppo devono essere semplici: divieto assoluto di complicazioni inutili, del resto è molto più semplice abbozzare un’idea o una parte di un software e poi migliorarlo successivamente quando si ha una conoscenza della situazione più approfondita
- Feedback – Un feedback continuo è importante in ottica di miglioramento e flessibilità nei confronti del team e del cliente
- Coraggio – Prendere decisioni importanti risulta fondamentale, anche ammettere però i propri errori è parte integrante di un “coraggioso processo”
- Rispetto – Umiltà e rispetto sempre e comunque di tutte ma proprio tutte le persone coinvolte nel progetto: in pratica in XP tutti coloro che prendono parte al progetto hanno voce in capitolo senza distinzione alcuna.
XP è inoltre un metodo di sviluppo del software che fa leva enormemente su TDD, di cui vi abbiamo parlato già in un articolo dedicato all’interno del blog di LaraMind. XP, anche se un po’ emarginato ultimamente, è molto ma molto diffuso ancora, specie all’interno di team di sviluppo che hanno un bisogno massivo di produrre codice di qualità.
Link Utili per chi volesse approfondire XP