Pair Programming

Il pair programming significa due sviluppatori che lavorano insieme a una postazione. Uno scrive (il driver); l'altro osserva, pensa e naviga (il navigator).

Sembra inefficiente. Stai pagando due persone per fare il lavoro di una. Ma i conti tornano in modo diverso da quanto ti aspetteresti:

• Meno bug raggiungono la produzione (il navigator cattura gli errori in tempo reale)
• La conoscenza si diffonde nel team (niente silos di conoscenza)
• La qualità del codice migliora (code review in tempo reale)
• Gli sviluppatori junior crescono più velocemente (imparando dai senior)
• La concentrazione migliora (è più difficile controllare Twitter quando qualcuno ti guarda)

Gli studi dimostrano che le coppie producono codice con il 15% di difetti in meno impiegando solo il 15% di tempo in più. Non è il doppio del costo per una qualità migliore—è un investimento del 15% per risultati drammaticamente migliori.

Il modello classico di pairing ha due ruoli:

Il Driver tiene la tastiera. Loro:

• Scrivono il codice
• Si concentrano sul compito immediato (sintassi, questa riga, questo test)
• Pensano tatticamente all'implementazione
• Parlano di quello che stanno facendo

Il Navigator osserva e pensa. Loro:

• Rivedono il codice mentre viene scritto
• Pensano strategicamente (questo design ha senso?)
• Tengono a mente il quadro generale
• Catturano errori di battitura, errori logici e problemi di design
• Cercano informazioni quando necessario

Scambiate i ruoli regolarmente. Ogni 15-30 minuti, cambiate. Questo mantiene entrambi i partner coinvolti e impedisce a una persona di dominare.

Il navigator non è passivo. Se stai navigando e vedi qualcosa di sbagliato, parlane immediatamente. Non aspettare. Il valore del pairing viene dal feedback continuo.

Ci sono diversi stili di pairing efficaci:

Ping-Pong Pairing (funziona benissimo con il TDD):

1. La persona A scrive un test che fallisce
2. La persona B lo fa passare e scrive il prossimo test che fallisce
3. La persona A lo fa passare e scrive il prossimo test che fallisce
4. Continuate alternandovi

Questo mantiene entrambe le persone attivamente a scrivere codice e mantiene la disciplina del TDD.

Strong-Style Pairing: "Perché un'idea passi dalla tua testa al computer, deve passare attraverso le mani di qualcun altro."

Il navigator dice al driver cosa scrivere. Il driver scrive solo; non prende decisioni. Questo è ottimo per insegnare—il junior scrive mentre il senior naviga, forzando il trasferimento di conoscenza.

Tour Guide Pairing: Una persona conosce il codebase; l'altra sta imparando. L'esperto guida e spiega, facendo un tour del codice. Poi si scambiano, con chi impara che tenta i compiti sotto guida.

Scegli lo stile che si adatta alla situazione. Ping-pong per il TDD. Strong-style per il mentoring. Tour guide per l'onboarding.

Il pairing funziona anche da remoto. Ti serve:

• Condivisione dello schermo con bassa latenza (VS Code Live Share, JetBrains Code With Me, o condivisione schermo con controllo remoto)
• Comunicazione vocale (connessione audio costante)
• Videocamera opzionale ma utile (vedere reazioni e linguaggio del corpo)

Consigli per il pairing remoto:

• Usa uno strumento che permetta a entrambi di scrivere (non solo condivisione schermo)
• Fai pause più frequenti—il pairing remoto è più stancante
• Comunica eccessivamente a voce (non puoi leggere il linguaggio del corpo altrettanto bene)
• Concordate le impostazioni dell'editor e le combinazioni di tasti prima di iniziare

Alcuni team trovano che il pairing remoto funzioni ancora meglio di quello di persona perché non c'è la tentazione di "sporgersi e prendere la tastiera". Ogni persona rimane nel proprio ruolo.

Fai pairing su:

• Problemi complessi dove due prospettive aiutano
• Percorsi di codice critici (autenticazione, pagamenti, integrità dei dati)
• Codice non familiare (una persona lo conosce, una sta imparando)
• Quando sei bloccato (una prospettiva fresca rompe gli stalli)
• Onboarding di nuovi membri del team

Considera il lavoro individuale per:

• Compiti semplici e di routine (aggiornare configurazioni, rinominare cose)
• Spike esplorativi (quando hai bisogno di pensare da solo)
• Quando una persona ha competenze profonde a cui l'altra non può contribuire

XP non impone il pairing al 100%, nonostante la credenza comune. L'XP originale specificava il pairing per il codice di produzione, ma l'XP moderno riconosce che i team efficaci mescolano lavoro individuale e in coppia in base al contesto.

La chiave: non lasciare mai che il codice vada in produzione senza revisione. Se non fai pairing, rivedilo. Il pairing è solo code review in tempo reale.

"I nostri sviluppatori non vogliono fare pairing." Inizia lentamente. Fai pairing solo sui problemi difficili. Lascia che le persone sperimentino i benefici. Non forzare il pairing al 100% dal primo giorno.

"Non possiamo permetterci due persone su un compito." Non puoi permetterti nemmeno i bug in produzione. L'economia favorisce il pairing quando consideri la riduzione dei bug, la conoscenza condivisa e la qualità del codice migliorata.

"Gli sviluppatori senior saranno rallentati." A volte. Ma i senior che fanno pairing con i junior accelerano l'intero team. La conoscenza del senior si diffonde. Il junior cresce. È un investimento nella capacità del team.

"Gli introversi odiano il pairing." Alcuni introversi amano il pairing perché è un'interazione strutturata con uno scopo chiaro. Altri hanno bisogno di tempo da soli per ricaricarsi. Rispetta i bisogni individuali, ma non assumere che introversione significhi anti-pairing.

"Il pair programming è estenuante." È più intenso del lavoro individuale. Fai pause. Non fare pairing per 8 ore di fila. Mescola il pairing con lavoro individuale, code review o lavoro di design.