Introduzione al Pair Programming: programmare in coppia

Salve a tutti e ben ritrovati per un nuovo episodio di Pensieri in Codice. Prima di addentrarci nell’argomento di oggi, vi rubo giusto un minuto per fare un paio di annunci. Innanzitutto è online il nuovo sito di pensieriincodice.it, dove trovate tutte le informazioni su dove seguire il podcast, come unirvi al gruppo o al canale Telegram, come partecipare alle discussioni e alle iniziative e, se volete, come sostenere il progetto e dimostrare il vostro apprezzamento anche senza spendere soldi. E comunque ricordate che anche solo condividere gli episodi con i vostri amici e conoscenti è già un aiuto molto apprezzato. In secondo luogo, volevo informarvi che dopo quasi un anno ho rispolverato il mio profilo coach su Docety. Se non la conoscete, Docety è la piattaforma di e-learning sulla quale è possibile seguire corsi, seminari o lezioni private in videoconferenza. Per ora io ho attivato il calendario per le lezioni private, quindi se volete fare un ripasso o un recupero di informatica per le scuole superiori, per corsi universitari o se siete interessati a una breve consulenza, cliccate sul link che trovate in descrizione e prenotate una sessione per parlare insieme e capire se è il caso di avviare un percorso di incontri personalizzati. La prima mezz’ora è gratuita. Per il futuro ho inoltre intenzione di caricare alcuni videocorsi e organizzare dei seminari, quindi mi raccomando restate sintonizzati. Detto questo direi di fermarci con le comunicazioni di servizio e passare a parlare dell’argomento del giorno. L’idea di registrare questo episodio mi è venuta in mente qualche settimana fa quando ho letto uno stupendo articolo sul blog di Martin Fowler. Vi lascio il link in descrizione perché è un ottimo punto di partenza per approfondire il tema di cui parleremo oggi. E qual è questo tema? Beh, l’avrete letto nel titolo. Si tratta di pair programming. Il pair programming è una tecnica che coinvolge due programmatori per lavorare allo stesso problema su un unico computer. Essi lavorano contemporaneamente ad una singola attività e si trovano a discutere i problemi, a pianificare le operazioni, a scrivere codice e a svolgere tutti i vari compiti rigorosamente assieme. Capisco che detta così, in due parole, questa tecnica potrebbe sembrare qualcosa di banale se non addirittura controproducente. Due persone che lavorano su un unico computer ad un’occhiata superficiale potrebbero dare l’impressione di stare sprecando tempo. Sicuramente verrebbe da pensare che una delle due stia lì a girarsi i pollici. In realtà, però, il pair programming, se svolto nel rispetto di tutta una serie di linee guida, può risultare enormemente efficace nel migliorare la qualità del codice e nel ridurre i tempi di sviluppo nel medio e nel lungo periodo, oltre poi ad avere effetti positivi su tutto il team, distribuendo la conoscenza del progetto, migliorando i rapporti interpersonali e favorendo il passaggio di abilità e competenze fra i membri della squadra. Cerchiamo però di non correre troppo e proviamo a capire in cosa consiste e quali sono i vantaggi del pair programming analizzando alcuni aspetti di questa tecnica. Ovviamente in un podcast di 15 minuti non potremo essere esaustivi sull’argomento e per questo motivo vi rimando all’articolo in descrizione per avere maggiori dettagli e capire come applicare la tecnica nel concreto. Noi qui ci limiteremo ad introdurre gli aspetti generici della questione. Iniziamo col dire che il pair programming si basa su una fortissima componente di pianificazione, su una buona comunicazione e su tutta una serie di regole più o meno varie da applicare a seconda del contesto, del carattere e delle abilità dei due componenti della coppia, della loro conoscenza della tecnologia e del progetto e di molte altre variabili. Non si tratta quindi banalmente di sedersi in due al pc e litigare su come scrivere una riga di codice. I due membri della coppia hanno in ogni momento due ruoli ben definiti e distinti e si occupano di aspetti diversi della risoluzione dello stesso problema. La programmazione, almeno quella fatta come si deve, è infatti un processo molto complesso, è necessario risolvere una miriade di piccoli problemi pratici come operazioni matematiche, gestione di valori nelle variabili, input, output, cicli, funzioni, accesso ai file, accesso ai database e qualsiasi altra cosa vi possa venire in mente, mentre al contempo bisogna tenere d’occhio il quadro generale, cercando di integrare al meglio le modifiche che si stanno effettuando all’interno di un progetto complessivo. Oltre a questo bisogna avere competenze sul dominio del problema da risolvere, sulla tecnologia che si sta utilizzando per risolverlo e sul progetto in cui si sta lavorando. Tutti questi compiti, che normalmente sono richiesti ad un unico sviluppatore o a più sviluppatori ma in tempi diversi, nel pair programming vengono essenzialmente suddivisi nella coppia e svolti in modo parallelo. I due programmatori lavorano quindi ad una parte del processo e ciascuno dei due si occupa di tenere conto solo di alcuni aspetti dello sviluppo. Nella più classica delle versioni del pair programming, i due membri si alternano nei ruoli di driver e navigator. Il driver è la persona con le mani sulla tastiera, quella che scrive effettivamente il codice. Egli si occupa di risolvere tutti i problemi pratici per conseguire un susseguirsi di micro obiettivi. Si può dire che nella coppia ha il ruolo tattico e quindi sceglie come implementare le funzioni, come passare le variabili, come organizzare i cicli, eccetera, e nel far ciò ignora appositamente la visione d’insieme e le questioni legate al dominio del problema. Inoltre, da un punto di vista pratico, è anche buona norma che, mentre lavora, il driver descriva ciò che sta effettuando non nel dettaglio quanto piuttosto nelle intenzioni. In pratica, mentre scrive il codice dovrà dire qualcosa del tipo ora creo una funzione per calcolare la media tra tre numeri oppure devo scorrere la matrice alla ricerca degli interi positivi e così via con indicazioni di questo tipo. Dal canto suo, invece, l’altro ruolo in gioco, il navigator, resta in una posizione di osservazione. Segue ciò che sta facendo il driver, fornendo informazioni sul problema e condividendo idee. In contrapposizione al proprio compagno, il navigator ha un ruolo strategico e tiene d’occhio il problema stando un passo indietro. Egli ha una visione di insieme sulla questione e quindi può dare indicazioni, raccogliere idee e appunti, anticipare le prossime mosse da fare o valutare eventuali problemi che potrebbero presentarsi nell’immediato futuro. Inoltre, potendo vedere il codice mentre viene scritto, può anche effettuarne al volo una code review, riducendo così enormemente il numero di potenziali bug. Ora, questa divisione dei ruoli può essere più o meno flessibile a seconda delle necessità, ma è molto importante che le due persone della coppia si scambino con una certa frequenza per poter svolgere parte del lavoro come driver e parte come navigator. Non è indispensabile che i due trascorrano lo stesso tempo interpretando entrambi i ruoli, ma è fondamentale che ciascuno sperimenti i panni dell’altro al fine di sapere come ci si sente e affinare la propria tecnica. Al tempo stesso, un eventuale squilibrio nella quantità di tempo speso in un ruolo piuttosto che in un altro è tranquillamente accettato e può dipendere da moltissimi fattori. In questa strategia, infatti, si lavora in coppia con l’obiettivo primario di ottenere un risultato migliore rispetto a ciò che potrebbe fare un singolo programmatore. Ed è quindi necessario sfruttare al massimo la combinazione dei punti di forza di cui si dispone e al tempo stesso ridurre al massimo le debolezze. Per questo motivo, se tra i due c’è un programmatore più esperto dell’altro nell’utilizzo della tecnologia impiegata o che conosce meglio il progetto o il dominio del problema, questi trascorrerà almeno all’inizio più tempo nel ruolo di navigator che in quello di driver. Così facendo, egli avrà modo di trasmettere le proprie competenze al partner, finché quest’ultimo non riuscirà a colmare il gap e quindi ristabilire una condizione di equilibrio. Abbiamo dunque visto a grandi linee cosa si intende per pair programming, ma in effetti quali sono i vantaggi di un approccio che almeno all’apparenza sembra così complesso da attuare? Beh, cominciamo dalle cose ovvie. Innanzitutto, in base a quanto ci siamo già detti nel primo blocco, è chiaro che con questa tecnica diventa possibile impiegare in modo proficuo due risorse per lavorare su un solo problema alla volta. Ed è quindi banale che, con il doppio della forza lavoro, i tempi necessari per completare un’attività, se non proprio addimezzati, risulteranno comunque molto ridotti. In secondo luogo, abbiamo detto anche questo anche se di sfuggita, il pair programming permette al navigator di fare code review al volo sul codice scritto dal driver. A prima vista potrebbe sembrare una banalità, ma questo semplice fatto implica la possibilità di scaricare da quest’onere un terzo membro del team, che avrebbe dovuto fare code review in un secondo momento, e risparmiare così una risorsa è molto tempo sprecato a segnalare il codice, modificarlo, riverificarlo, eccetera. Infine, la possibilità di affiancare un navigator esperto del progetto o della tecnologia ad un driver meno esperto, o addirittura ad una risorsa appena entrata nel team, non è certo un vantaggio da sottovalutare. Pensate a quando si è nuovi o inesperti. Si trascorre molto più tempo a cercare di capire come funziona il progetto che a risolvere effettivamente le proprie attività. Si è costretti a chiedere a chi è più esperto, si incappa spesso in errori banali come implementare codice molto simile a quello che già esiste, e altri problemi del genere. Nel pair programming tutto questo non esiste. Il collega esperto è proprio lì accanto, nel ruolo di navigator, ed è pronto a dare suggerimenti ed eventualmente spiegare parti del software che il driver ancora non conosce. Al di là di questi vantaggi che sono tutto sommato intuibili, però questa tecnica nasconde anche un’altra serie di benefici che potrebbero non apparire così evidenti. Lavorare in coppia, infatti, produce di per sé una serie di vantaggi e innesca delle dinamiche psicologiche molto differenti rispetto al lavoro in solitaria. Infatti, il pair programming ad esempio incoraggia enormemente la riflessione. Due persone che affrontano lo stesso problema in coppia tendono appunto a confrontarsi. Non cercano la soluzione ragionando solo con la propria testa, ma esternano pensieri e riflessioni, giungendo insieme all’obiettivo in modo più rapido ed efficace. In secondo luogo, lavorare in coppia mantiene alto il livello di concentrazione ed evita le divagazioni. Questo perché, quando si lavora con un collega, si tende ad avere un approccio più strutturato. Il pensiero va comunicato ad un’altra persona e per far ciò è necessario riordinare le proprie idee. Avere poi un compagno che ti freni quando si rende conto che il tuo ragionamento sta deraiando è sicuramente un grosso aiuto per evitare di sprecare tempo addentrandosi in vicoli ciechi o soluzioni inapplicabili. E poi ancora, con il pair programming si attuano contemporaneamente due modelli di pensiero differenti. I ruoli del driver e del navigator sono proprio la personificazione di un modello di pensiero tattico e di uno strategico, dell’attenzione al dettaglio e di quella al quadro d’insieme, dell’azione e della pianificazione. E se ci pensiamo, è veramente difficile trovare una persona che da sola riesca a fare tutto questo contemporaneamente. Ma quindi il pair programming è la soluzione a tutti i mali dello sviluppo software? Dovrebbe essere applicato in qualsiasi progetto? Come al solito la faccenda non è così semplice. Il pair programming è una tecnica. Un’ottima tecnica, ma pur sempre una tecnica che presenta tanti vantaggi ma anche tanti svantaggi. Ad esempio può essere molto stancante. Proprio per via del notevole impiego di energie nella comunicazione e nella concentrazione necessarie per coordinare il lavoro, questa tecnica può pesare sulle forze dei due partner al punto che gli esperti sconsigliano di applicarla per più di 6 ore al giorno e in caso di utilizzo continuativo consigliano anche periodi di pausa per lavoro in solitaria. Oltre a questo, il pair programming può anche essere complicato da organizzare. Se uno dei due programmatori o anche entrambi ricevono molte richieste o interruzioni durante il giorno, se devono partecipare a molte riunioni distribuite in vari orari, trovare il tempo di dedicarsi contemporaneamente alla stessa attività può diventare complicato e stressante. E a tutto questo va poi aggiunto che possono esserci difficoltà nei rapporti tra le persone, magari per motivi caratteriali o per dinamiche aziendali. E lavorare in coppia, quando non si va d’accordo o si hanno visioni troppo differenti sul modo di progettare e realizzare software, significa passare il tempo a litigare o, nel migliore dei casi, che uno o entrambi reprimano il proprio carattere riducendo l’apporto produttivo alla coppia, rendendo il tutto non sostenibile nel lungo periodo. D’altro canto, accoppiare persone troppo distanti per esperienza o anzianità o per gerarchia può rendere la coppia squilibrata, con uno dei due elementi che avrà timore di condividere le proprie idee e asseconderà eccessivamente l’altro. Insomma, il pair programming non è la cura miracolosa e non ha nemmeno una ricetta univoca per l’applicazione, ma è comunque una tecnica molto efficace che porta grandi benefici sia ai progetti che ai programmatori. In definitiva, se non l’aveste mai fatto, io vi consiglio di provarla o proporla nell’azienda in cui lavorate, e magari potreste anche condividere questo podcast con i colleghi per introdurre l’argomento. Detto questo, non mi resta che ringraziarvi per l’ascolto, darvi appuntamento al prossimo episodio e ricordarvi che… Il programmatore risolve i problemi, a volte, anche usando il computer.