Pair Programming: la collaborazione per la qualità del codice

25 Luglio 2023

Una scrivania. Una scrivania, due colleghi. Una scrivania, due colleghi, una postazione.
Un solo codice.
Questo è il pair programming.
Ma quali sono i benefici per le persone e il team? E perché è necessario applicarlo, o perlomeno sperimentarlo?

Indice

La pratica di Pair Programming
I ruoli
Pair programming: perché sì, i vantaggi
Elastic Pair Programming
- L’unica regola dell’Elastic Pair Programming
Punti di attenzione: i rischi
Conclusioni
Risorse

La pratica di Pair Programming

Pair Programming è una pratica di Extreme Programming in cui due sviluppatori lavorano alla stessa postazione sullo stesso codice. Il pair programming ha ruoli, regole e tempi da rispettare. Tale disciplina è uno dei punti di forza della pratica.

Approfondiamo meglio i ruoli.

I ruoli

I developer sono davanti alla stesso schermo con due ruoli differenti:

Driver

Il “conducente”, colui che digita. Scrive il codice, è concentrato sui dettagli implementativi.

Navigator

Il “navigatore”, colui che dà prospettiva. Aiuta il driver a mantenere il focus, annota e ordina gli step che portano alla soluzione desiderata.

Una sessione dura in genere 20-30 minuti. Al termine della sessione di programmazione, la coppia fa una breve retrospettiva e definisce gli obiettivi per la prossima iterazione. Dopodiché le persone si scambiano di ruolo e inizia una nuova iterazione. Una pausa più lunga è prevista ogni 2h. Questo ritmo permette di mantenere alta l’attenzione e promuovere i differenti punti di vista.

Pair programming: perché sì, i vantaggi

Ci sono più motivi che rendono il pair programming una interessante opportunità. Vediamoli di seguito.

Collaborazione e condivisione know-how

Tra il navigator e il driver c’è un dialogo continuo. Questo innesca una profonda collaborazione tra colleghi. La necessità di verbalizzare le soluzioni tecniche prima della loro implementazione rinforza la capacità di comprendere, elaborare e infine trasmettere i concetti.
La pratica è un momento di apprendimento: non è insolito che due persone con livello di esperienza diversi lavorino in coppia, facendo fluire il know-how del dominio applicativo. Si aprono discussioni in merito ai dettagli del linguaggio, ai pattern, o ai differenti approcci maturati nell’esperienza lavorativa.
Inoltre, almeno due persone sanno con quale logica è stato scritto quel codice, un vantaggio per l’intero team.

Riduzione di bugs ed errori

Il detto “Quattro occhi sono meglio di due” calza a pennello. E’ provato che nel pair programming si riduce il numero di bug. Il focus del driver produce codice efficace, mentre l’occhio vigile del navigator attenua la possibilità di errore.
Nella descrizione presente sulla C2 Wiki, sono riportate le statistiche a supporto della pratica. Lo studio di Laurie Williams, dell’università dello Utah a Salt Lake City, mostra una riduzione di bug del 15%. Risultato notevole, considerando il costo di risoluzione spesso elevato e le conseguenze economiche a danno degli utenti.

Codice migliore: il ruolo della creatività

La qualità del codice scritto in pair programming è statisticamente migliore. Il confronto continuo favorisce la creatività. La coppia esplora strade diverse, emergono soluzioni inaspettate. Ne deriva software con una struttura più flessibile e chiara.

Elastic Pair Programming

Dopo anni di pratica, un team stabile raggiunge un’elevata padronanza del proprio dominio applicativo, delle tecnologie e delle tecniche adottate dal team.
A quel punto, il pair programming “classico” finisce spesso per andare stretto. In queste occasioni è possibile allentare un po’ le regole e passare ad una modalità di lavoro più elastica, appunto l’Elastic Pair Programming.

Per capire se è il caso di usare questo approccio bisogna farsi una domanda: “Sapresti risolvere da solo questo problema?”. Se la risposta è qualcosa tipo “Sì, ma sono curioso di sapere come lo risolverebbe -inserisci qui il nome-”, ci sono i presupposti per una buona sessione di elastic pair programming.

L’unica regola dell’Elastic Pair Programming

Il nome rappresenta bene la caratteristica principale dell’approccio, ovvero l’elasticità di regole e ruoli. Di regole ce n’è solo una: ci si scambiano idee (e tastiera) in continuazione.
Rilassando le regole “classiche”, consentendo ad esempio di prendere la tastiera in qualsiasi momento, si abilita un confronto più diretto, schietto, dove anche chi ha molta esperienza ha l’opportunità di mettere in discussione assunti e preconcetti.

Punti di attenzione: i rischi

Il pair programming è una competenza che va coltivata. Non basta sedersi assieme davanti a un PC. Occorre inoltre fare attenzione alla composizione delle coppie, al feedback raccolto durante le sessioni e alle persone coinvolte.

Alcuni rischi possono essere:

Mal assortimento del pair: in una coppia con livelli di competenza troppo distanti, formata ad esempio da un senior di lunga data e dalla persona junior appena arrivata, potrebbe annoiare la prima e spaventare la seconda, minando la pratica e i rapporti fra le persone.
Fare sempre e solo Pair Programming: discutere e confrontarsi per l’intera giornata lavorativa è un esercizio molto intenso. Su alcuni sviluppi triviali o in attività a basso carico cognitivo le persone possono lavorare in autonomia.
Usare sempre lo stesso formato: ci sono diversi modi di fare Pair Programming, dallo “Strong Style” alla modalità “Ping Pong”. Variare formato, aggiungendo qualche elemento di gamification porta la coppia a sopportare meglio le sessioni.

Parlando di Elastic pair programming invece:

L’ approccio può diventare facilmente un sistema proprio per non fare pair programming; non avendo “obblighi”, è facile cadere nell’anti-pattern in cui il driver scrive codice e lavora da solo, mentre il navigator pensa ad altro. Anche in assetto da (elastic) pair programming vanno stabiliti dei working agreement, come ad esempio tenere alla larga smartphone e distrazioni.

Conclusioni

Una scrivania. Una scrivania, due colleghi. Una scrivania, due colleghi, una postazione. Un solo codice, di qualità migliore. Questo è il pair programming.
Nonostante ci siamo dei rischi a cui prestare attenzione, la pratica consente una collaborazione e una condivisione del linguaggio maggiore diventando un momento di apprendimento. I bug e gli errori sono ridotti, abbassando i costi economici e di risoluzione. La creatività e il coinvolgimento delle persone è più alto. Quelli appena descritti sono alcuni degli aspetti positivi dell’applicazione del pair programming. Quindi sì, vale la pena testarlo e vedere gli effetti sul proprio team.

Per approfondire un’altra pratica di sviluppo software in team, consigliamo la lettura dell’articolo Mob Programming, una pratica di sviluppo software per ridurre il tempo di rilascio.