Pair Pro­gram­ming: il principio del doppio controllo nello sviluppo di software

Lo sviluppo di un nuovo software è una vera impresa. A seconda del­l'en­ti­tà del programma, bisogna tener conto di svariate even­tua­li­tà, funzioni e criticità. Persino agli svi­lup­pa­to­ri esperti può capitare di di­so­rien­tar­si. Per rendere la pro­gram­ma­zio­ne quanto più ef­fi­cien­te possibile ga­ran­ten­do al contempo un codice senza errori, negli ultimi anni e decenni sono stati svi­lup­pa­ti moderni metodi di lavoro: Scrum e Kanban, ad esempio, mirano a mi­glio­ra­re l'intero sistema.

Il pair pro­gram­ming è un po' meno ambizioso: in questo caso gli svi­lup­pa­to­ri lavorano sempre in due su un codice. Come funziona questo metodo di lavoro e quali sono i suoi vantaggi?

Il metodo del pair pro­gram­ming è uti­liz­za­to pre­va­len­te­men­te nello sviluppo agile di software e richiesto con­cre­ta­men­te nell'extreme pro­gram­ming (XP). Nel pair pro­gram­ming due persone lavorano sempre con­tem­po­ra­nea­men­te allo stesso codice, nella migliore delle ipotesi sedute una accanto all'altra. Una scrive il codice, l'altra lo controlla in tempo reale. Nel frattempo si ha uno scambio continuo: i due svi­lup­pa­to­ri discutono le pro­ble­ma­ti­che, trovano possibili soluzioni, svi­lup­pa­no idee creative.

Di norma ai due col­la­bo­ra­to­ri spettano due ruoli diversi: il pro­gram­ma­to­re detto pilota scrive il codice. Il co­sid­det­to na­vi­ga­to­re, invece, lo controlla. Una delle regole del pair pro­gram­ming è che i due si scambino re­go­lar­men­te (e a breve in­ter­val­li) i ruoli. Si evita così una dif­fe­ren­za ge­rar­chi­ca: i due hanno infatti uguali diritti e possono anche tran­quil­la­men­te su­ben­tra­re nel ruolo del­l'al­tro.

Anche il luogo di lavoro va ideal­men­te adeguato ai requisiti del pair pro­gram­ming. Entrambi i col­la­bo­ra­to­ri devono avere a di­spo­si­zio­ne mouse, tastiera e monitor; gli schermi però devono vi­sua­liz­za­re la stessa cosa.

Più insolito è invece il co­sid­det­to pair pro­gram­ming remoto. In questo caso i due pro­gram­ma­to­ri non sono seduti uno accanto all'altro, ma si trovano in luoghi com­ple­ta­men­te diversi. Perché il metodo funzioni, servono soluzioni tecniche speciali. No­no­stan­te la distanza, i due colleghi devono poter co­mu­ni­ca­re di­ret­ta­men­te tra di loro, accedere al codice e vi­sua­liz­za­re le modifiche in tempo reale.

Nella pratica, spesso a col­la­bo­ra­re sono due svi­lup­pa­to­ri con un livello di espe­rien­za diverso: in questo modo, un pro­gram­ma­to­re molto esperto può tra­sfe­ri­re di­ret­ta­men­te il know-how al collega più giovane. Que­st'ul­ti­mo, a sua volta, può avere idee più fresche da mettere a di­spo­si­zio­ne del progetto.

Anche la col­la­bo­ra­zio­ne tra due colleghi pro­ve­nien­ti da campi diversi può dare buoni frutti: se ad esempio un pro­gram­ma­to­re classico collabora con un designer, i due possono offrirsi supporto reciproco con la ri­spet­ti­va com­pe­ten­za.

Il pair pro­gram­ming ha senso so­prat­tut­to nei progetti più grandi. Infatti, con grandi quantità di codice da mo­di­fi­ca­re re­go­lar­men­te, il principio del doppio controllo risulta par­ti­co­lar­men­te efficace. Si ha così la sicurezza che nel codice sorgente si trovi sempre la versione migliore possibile di un segmento: di con­se­guen­za, scende la necessità di in­ter­ven­ti cor­ret­ti­vi suc­ces­si­vi e cala il numero degli errori. Il controllo suc­ces­si­vo di un codice sorgente molto lungo richiede molto tempo e impegno, per cui è più van­tag­gio­so evitare il più possibile gli errori a monte.

In più, anche al­l'in­ter­no di un progetto, non è ne­ces­sa­rio che col­la­bo­ri­no sempre gli stessi colleghi. Anzi, è un vantaggio rias­sor­ti­re re­go­lar­men­te le coppie. Così ogni com­po­nen­te del team avrà una buona co­no­scen­za del­l'in­te­ro codice sorgente. Inoltre, in questo modo il successo di un progetto non dipenderà solo ed esclu­si­va­men­te da singole persone. In caso di assenza di una persona, poi, non ci saranno ri­per­cus­sio­ni sul­l'in­te­ro progetto, visto che tutti gli altri possono prendere il posto del collega assente.

Che si tratti di pro­gram­ma­zio­ne o di un altro progetto, lavorare in due assicura numerosi vantaggi. Due teste sono meglio di una: il rischio di errori si riduce al minimo con il pair pro­gram­ming. Mentre una persona scrive, l'altra tiene sempre sotto controllo il codice e si concentra nel­l'in­di­vi­dua­re eventuali errori. Spesso è difficile trovare i propri errori. Un collega, invece, scova molto più ve­lo­ce­men­te le in­con­gruen­ze.

Anche la crea­ti­vi­tà derivante dalla co­mu­ni­ca­zio­ne è un grande vantaggio: lo scambio continuo tra i due pro­gram­ma­to­ri dà vita a idee che non sarebbero nate lavorando da soli. Lo scambio co­mu­ni­ca­ti­vo tra i due col­la­bo­ra­to­ri consente anche di trovare soluzioni migliori ai problemi, più ra­pi­da­men­te. Perché se una persona da sola si ac­con­ten­ta della prima opzione trovata, nel pair pro­gram­ming la sua decisione deve essere sempre giu­sti­fi­ca­ta davanti al collega, che potrebbe avere una visione diversa del problema e non essere quindi d'accordo con la soluzione proposta. Dalla di­scus­sio­ne che ne deriva spesso nascono idee che portano a un codice de­ci­sa­men­te migliore.

Un buon codice è alla fin fine un codice agile: l'e­spe­rien­za dimostra che il codice sorgente che risulta dal pair pro­gram­ming è spesso più breve e quindi più efficace. Un vantaggio che si traduce nel­l'u­ti­liz­zo di meno risorse per la ma­nu­ten­zio­ne e il ri­ma­neg­gia­men­to.

Come detto, questa tecnica può essere uti­liz­za­ta anche per per­met­te­re ai la­vo­ra­to­ri esperti di tra­smet­te­re le proprie co­no­scen­ze ai più giovani. Così si ap­pro­fit­ta non solo del vantaggio effettivo del pair pro­gram­ming, vale a dire la creazione di codici di alta qualità, ma il metodo può assolvere anche a scopi di for­ma­zio­ne.

Si tratta però di un processo che richiede molto tempo: è vero che due pro­gram­ma­to­ri lavorano più ve­lo­ce­men­te insieme che non da soli, ma è anche vero che non lavorano ve­lo­ce­men­te quanto due pro­gram­ma­to­ri che lavorano ognuno per conto proprio. Ciò significa che con questo metodo i progetti procedono più len­ta­men­te oppure che bisogna impiegare più personale, con un con­se­guen­te aumento dei costi. I so­ste­ni­to­ri del pair pro­gram­ming partono dal pre­sup­po­sto che il maggiore lavoro richiesto al­l'i­ni­zio sarà ripagato in seguito: perché il codice ri­sul­tan­te contiene meno errori e nel complesso è strut­tu­ra­to meglio, pertanto gli in­ter­ven­ti di ma­nu­ten­zio­ne saranno molto meno.

Un altro possibile svan­tag­gio è che il pair pro­gram­ming è sì indicato per il team building, ma solo quando i due colleghi possono lavorare bene insieme. I due pro­gram­ma­to­ri devono lavorare a stret­tis­si­mo contatto, tanto che i problemi personali tra i due possono ral­len­ta­re l'a­van­za­men­to del progetto o dare luogo a una vera e propria esca­la­tion. Pertanto in questo metodo i col­la­bo­ra­to­ri non vanno abbinati a caso. L'ideale è poter col­la­bo­ra­re ogni volta con un collega diverso, ma può fun­zio­na­re solo quando c'è una grande armonia in tutto il team.