Questa voce o sezione sull'argomento informatica è ritenuta da controllare.
Motivo: L'articolo è una traduzione dell'omonimo articolo in inglese in cui sono state rimosse parti fondamentali per la comprensione dell'argomento. Il contenuto, quando non sbagliato, è fuorviante
La programmazione estrema, meglio nota come extreme programming (XP), è una metodologia di sviluppo del software mirata a migliorare la qualità del codice e la responsività al cambiamento dei requisiti del cliente. In quanto tipo di metodologia di sviluppo agile,[1][2][3] prescrive uno sviluppo in cicli brevi con pubblicazioni frequenti, con lo scopo di migliorare la produttività e introdurre punti di controllo nei quali i nuovi requisiti possono essere adottati.
Altri elementi della programmazione estrema comprendono la cosiddetta programmazione in coppia (pair programming) o fare un'estesa revisione di codice, test unitari del codice, non lavorare su funzionalità finché non sono necessarie, una struttura di gestione piatta, semplicità e chiarezza del codice, aspettarsi cambiamenti dei requisiti con il passare del tempo e con la migliore comprensione del problema e infine l'importanza data alla comunicazione diretta e frequente fra sviluppatori e cliente e fra gli sviluppatori stessi.[2][3][4] La metodologia prende il nome dall'idea di portare a livelli "estremi" gli elementi positivi delle consuete pratiche di ingegneria del software. Ad esempio, portare all'estremo le revisioni di codice, considerate una buona prassi, implica che il codice possa essere revisionato continuativamente, come nella programmazione in coppia.
Regole
Le dodici regole (o pratiche) che sono alla base dell'extreme programming possono essere raggruppate in quattro aree.
Feedback a scala fine
Pair programming - Due programmatori lavorano insieme su una sola workstation, il driver è colui che scrive il codice mentre il navigator ragiona sull'approccio e pensa se può funzionare. Questo rende il codice prodotto di migliore qualità. I due programmatori devono avere la stessa esperienza.
Planning Game - è una riunione di pianificazione che avviene una volta per iterazione, tipicamente una volta a settimana.
Whole Team - in XP, il "cliente" non è colui che paga il conto, ma la persona che realmente utilizza il sistema. Il cliente deve essere presente e disponibile a verificare (sono consigliate riunioni settimanali o Jour fixe).
Processo continuo
Integrazione continua - Integrare continuamente i cambiamenti al codice eviterà ritardi più avanti nel ciclo del progetto, causati da problemi d'integrazione.
Refactoring o Design Improvement - riscrivere il codice senza alterarne le funzionalità esterne, cambiando l'architettura, in modo da renderlo più semplice e generico.
Small Releases - consegna del software avviene tramite frequenti rilasci di funzionalità che creano del valore concreto.
Comprensione condivisa
Coding standards - Scegliere ed utilizzare un preciso standard di scrittura del codice. Questo rappresenta un insieme di regole concordate, che l'intero team di sviluppo accetta di rispettare nel corso del progetto.
Collective code ownership - significa che ognuno è responsabile di tutto il codice; quindi contribuisce alla stesura chiunque sia coinvolto nel progetto.
Simple design - i programmatori dovrebbero utilizzare un approccio del tipo "semplice è meglio" alla progettazione software. Progettare al minimo e con il cliente.
System metaphor - descrivere il sistema con una metafora, anche per la descrizione formale. Questa può essere considerata come una storia che ognuno - clienti, programmatori, e manager - può raccontare circa il funzionamento del sistema.
Benessere dei programmatori
Sustainable pace - il concetto è che i programmatori o gli sviluppatori software non dovrebbero lavorare più di 40 ore a settimana.
Modello dei processi
James Donovan Wells individua quattro linee guida:
comunicazione (tutti possono parlare con tutti, persino l'ultimo dei programmatori con il cliente);
semplicità (gli analisti mantengano la descrizione formale il più semplice e chiara possibile);
verifica (sin dal primo giorno si prova il codice);
coraggio (si dà in uso il sistema il prima possibile e si implementano i cambiamenti richiesti man mano).
Individua inoltre quattro fasi di progetto, ognuna delle quali con le sue regole interne:
pianificazione (user stories, release planning, small releases, project velocity, load factor, iterative development, iteration planning, move people around, daily stand up meeting, fix XP);
progettazione (simplicity, system metaphor, CRC cards, spike solution, never add early, refactoring);
sviluppo (Customer Always Available, Standards, Unit Test First, Pair Programming, Sequential Integration, Integrate Often, Collective Code Ownership, Optimize Last, No Overtime);
collaudo (unit test framework, bug's found, functional test o acceptance tests).
^abDesign Patterns and Refactoring (PPT), su cis.upenn.edu, Università della Pennsylvania, 2003. URL consultato il 21 gennaio 2023 (archiviato dall'url originale il 2 agosto 2010).
