El món de desenvolupament de software pot arribar a ser molt dur, pel que els desenvolupadors han anat creant noves i innovadores tècniques per optimitzar el procés. D’entre les més estrafolàries com el mètode de l’aneguet de goma a les més dures com el “crunching”, avui us parlarem del Pair Programming, altrament conegut com Programar per parelles. En aquest article us parlaré de què és i com el duem a terme a Basetis, així com alguns dels beneficis i desavantatges que ens hem trobat.
 

Què és el Pair Programming?

La idea bàsica del Pair Programming la porta el nom, i és tenir dos programadors treballant al mateix moment sobre el mateix tros de codi. Òbviament, tenir dos parells de mans alhora sobre el mateix teclat no és gaire pràctic (i menys si han de compartir ratolí), pel que normalment dos programadors compartiran pantalla, però només un dels dos actuarà en el moment. Aquest programador, anomenat driver, anirà canviant de forma periòdica amb el seu company, el shotgun, de manera que els dos han de ser molt conscients del que estan fent en tot moment, tant ell com el company.

Dintre del Pair Programming, a Basetis normalment ens distingim dues modalitats: extern i intern. El Pair Programming extern consisteix en el fet que una persona, anomenada Code Coach, ve a donar un cop de mà a un altre desenvolupador, anomenat host. El perfil del Code Coach acostuma a ser de desenvolupador sènior, amb experiència desenvolupant codi, així com aplicant pràctiques de Bon Codi. L’objectiu del mode extern és que serveixi per avançar el projecte del host i ajudar-lo a programar d’una manera més eficient en general. En general, el Code Coach no tindrà experiència prèvia en el projecte.

Per altra banda, el Pair Programming intern no té cap figura de Code Coach, sinó que són dues persones del mateix equip amb un nivell d’experiència bastant semblant que treballen juntes. Tot i que aquest mètode no implica tant aprenentatge com l’extern, pot ser més eficient, ja que ambdues persones coneixen ja el projecte i es pot ser menys formal en la preparació i gestió posterior.
 

Com fer-ho: eines i procediment

A continuació detallo els passos que es duen a terme en el cas de Pair Programming extern.

  1. Preparació: La iniciativa de fer un Pair Programming pot sortir del Code Coach o de l’equip. A Basetis es va crear un equip de Code Coaches que es dedicaven a buscar potencials projectes per fer Pair Programming. Tot i això, els casos més comuns són els interns, que es donen quan els Project Manager d’un equip insisteixen en el fet que els desenvolupadors facin Pair Programming.
  2. Introducció: Un cop triada la parella i el dia, comença la sessió. La primera part de la sessió (uns 30 minuts) normalment es dediquen a introduïr al nouvingut al tros de codi en qüestió, discutir els possibles problemes i decidir quines tasques es faran.
  3. Activitat: Un cop decidides les tasques, es duu a terme el Pair Programming en si, el primer driver acostuma a ser el host i el shotgun és el nouvingut. Cada 30 minuts, es canvia el rol dels dos programadors.
  4. Tancament: Un cop acabada la sessió (normalment d’unes 3 h + descans), és útil tenir un petit formulari preparat per a les dues parts per tal de poder deixar comentaris i millorar en el futur.

 

Abans de la pandèmia, la millor manera de fer Pair Programming era fent-ho seient davant la mateixa pantalla. Avui dia, això no és possible, i a Basetis utilitzem Visual Studio Live Share. Aquesta extensió gratuïta de l’IDE gratuït Visual Studio Code permet compartir en viu un mateix IDE, de tal manera que les dues persones poden tocar un mateix arxiu alhora. A Basetis hem tingut molts bons resultats utilitzant aquesta eina i una aplicació de trucades per veu (Google Meet, Zoom, Discord, etc.).

En cas de fer Pair Programming intern, la principal diferència és que no fa falta ser gaire formal i fer formularis abans i després de la sessió, però sí que és positiu trobar una manera de tenir feedback del procés.

L’experiència a Basetis ens demostra que 30 minuts és el temps ideal per persona, ja que és el temps suficient per a concentrar-se en el codi, però al mateix moment no és tant per tenir un monopoli sobre el mateix. El nombre de sessions de 30 minuts pot variar, però el mínim hauria de ser introducció + 4 sessions + descans, però 6 sessions acostumen a ser el més òptim. Veureu que un cop començat el Pair Programming és més beneficiós seguir-ho fent que parar i deixar-ho per un altre dia.

 

Quins beneficis i desavantatges té?

Hi ha diversos estudis sobre el Pair Programming, en els quals es demostra que el Pair Programming té efectes neutrals o positius respecte a programar en solitari. Els principals avantatges trobats són la reducció del nombre d’errors, la millora de la qualitat del codi, l’aprenentatge i la satisfacció a l’hora de programar. Els primers dos són els més visibles i directes, ja que com diu la dita, 4 ulls veuen més que 2. Els altres dos avantatges són beneficis més intangibles, però també importants perquè un equip sigui sostenible a llarg termini. A Basetis hem observat tots aquests beneficis, especialment l’aprenentatge i la millora de la qualitat de codi.

El principal desavantatge del Pair Programming és la inversió de temps i diners, especialment en el mode extern. Tenir dues persones fent la feina d’una persona és costós pel que fa al temps i diners, especialment si el Code Coach és un perfil sènior i per tant el seu cost per hora és molt alt. Tot i això, els estudis i la nostra experiència demostren que la inversió extra de temps i diners compensa de sobra la despesa d’arreglar els errors de més que es generen en programar en solitari, sigui en el mètode extern o intern.

Diversos estudis i l’experiència de Basetis demostren que els beneficis del Pair Programming superen els desavantatges

Per altra banda, un criticisme comú és la frase de Fred Books: “El que un programador pot fer en un mes, dos programadors ho poden fer en dos mesos”. Aquesta frase, però, fa referència als problemes de coordinar un equip de programadors i com afegir programadors a una tasca o problema, a vegades resulta que en lloc d’escurçar el temps d’execució, s’allarga. Això no aplica al Pair Programming, ja que els problemes als quals fa referència el Sr. Brooks són deguts a la falta de comunicació, cosa que no es dóna en Pair Programming.

 

Conclusió

Espero que amb aquests arguments i explicacions us hagi quedat clar com i perquè fem servir Pair Programming a Basetis. Tenim tant equips interns com de client que l’apliquen amb resultats positius, tot i que a vegades costa convèncer als clients.

Tot i això, hem aconseguit demostrar els beneficis de la seva aplicació a través de diversos equips de desenvolupament, i us animem a provar-ho! La primera vegada sempre és una mica incòmode, però a mesura que passa el temps i us familiaritzeu amb el codi i el company, l’experiència millora exponencialment.

A més, en aquest temps de pandèmia, fer Pair Programming també aporta una sensació de comunitat a un equip que és difícil replicar en aquest ambient de teletreball.

Foto de: Alvaro Reyes on Unsplash

desenvolupament,development,Open,pair programming,Top post,