Extreme programming: perché è essenziale, in tutti i sensi

Nel mondo della programmazione, si sente molto spesso parlare di Extreme Programming. Conosciuto anche con l’abbreviazione XP, questo approccio si traduce in italiano con ‘programmazione estrema’. Altro non è che una metodologia di sviluppo software che mette in primo piano la scrittura del codice.

A svilupparlo in origine è stato Kent Beck, tra le firme del celebre manifesto Agile oltre che coideatore del TDD. Grazie al suo lavoro e al prezioso aiuto di Ward Cunningham e Ron Jeffries, l’XP ha raggiunto una buona popolarità tra gli anni Novanta e i primi anni 2000.

Il mantra della community è stato fin da subito molto chiaro: per operare al meglio, i programmatori devono evitare di scrivere stringhe di codice non strettamente necessarie. Partendo da qui, si possono poi approfondire le 12 regole pratiche di sviluppo.

Le regole di sviluppo

Come appena ricordato, quando ci si muove nel campo dell’Extreme Programming è necessario considerare ben 12 regole di sviluppo, che sono le seguenti.

1. Pair Programming: due programmatori che lavorano assieme su una medesima workstation;
2. Planning Game: riunione di pianificazione che avviene circa una volta a settimana;
3. Test Driven Development: test automatici concretizzati prima di iniziare la scrittura del codice;
4. Whole Team: presenza del cliente, ossia colui che utilizzerà realmente il sistema, alle riunioni settimanali;
5. Refactoring: riscrittura del codice senza alterazione delle sue funzionalità esterne;
6. Continuous Integration: integrazione continua di cambiamenti al codice, così da evitare ritardi nel corso del progetto;
7. Small Release: consegna del software tramite rilasci frequenti di funzionalità;
8. Coding Standard: scelta e utilizzo di un determinato standard di scrittura del codice;
9. Collective Code Ownership: contributo alla scrittura del codice da parte di ogni membro del team di sviluppo;
10. Simple Design: ricorso ad un approccio il più semplice possibile in fase di sviluppo;
11. System Metaphor: capacità di descrivere, anche in sede di illustrazione formale, il sistema intero con una metafora;
12. Sustainable Pace: creazione di un ambiente di lavoro che permetta agli sviluppatori di lavorare massimo 40 ore a settimana.

Oltre che di regole pratiche, è necessario parlare anche di modelli. James Donovan Wells, uno degli autori di punta per chi vuole documentarsi sul mondo XP, ne ha individuati quattro. Il primo è la comunicazione. Secondo il suo approccio, tutti possono parlare con tutti e anche il programmatore con meno esperienza ha diritto di interagire con il cliente.

Il secondo punto riguarda invece la semplicità, linea guida che deve governare qualsiasi descrizione formale di progetto. Il terzo modello riguarda invece la verifica fin dal primo giorno di partenza del progetto stesso, mentre il quarto ha a che fare con il coraggio di dare subito in uso il sistema e di farsi trovare pronti a cambiamenti e implementazione.

I valori

Accanto alle regole di sviluppo e ai modelli, quando si parla di Extreme Programming è necessario discutere anche di valori, cominciando dalla qualità della comunicazione tra i membri del team e tra il team di sviluppo e il cliente finale.

Si passa poi alla già citata semplicità, che deve essere messa in primo piano sia nei processi di sviluppo, sia in fase di interazione con il cliente finale e di spiegazione del progetto. Essenziale è anche il feedback continuo, aspetto nodale in ottica di ottimizzazione tecnica e di miglior flessibilità.

Anche se ultimamente ha perso un po’ di terreno rispetto ai decenni passati, l’Extreme Programming rimane comunque un metodo di sviluppo software molto diffuso e apprezzato. Basato sul TDD (Test Driven Development), rappresenta ancora oggi un punto di riferimento basilare per quei team che necessitano di scrivere codice di qualità.