Pair Pro­gra­m­mi­ng: principio de los cuatro ojos en el de­sa­rro­llo de software

El de­sa­rro­llo de un software nuevo no es un proceso sencillo. De­pe­n­die­n­do del tamaño del programa, se deberá tener en cuenta una gran cantidad de posibles co­yu­n­tu­ras, funciones y cue­s­tio­nes pro­ble­má­ti­cas. Incluso los de­sa­rro­lla­do­res de software más expertos pueden llegar a des­orie­n­tar­se. De ahí que en estos últimos años se hayan ido de­sa­rro­lla­n­do otros métodos de trabajo más modernos que permiten programar con mayor efi­cie­n­cia y generar un código libre de errores: Scrum y Kanban sirven, por ejemplo, para mejorar el sistema completo.

El pair pro­gra­m­mi­ng no trata de abarcar tanto: los de­sa­rro­lla­do­res trabajan siempre por pares en el código. ¿Cómo funciona y cuáles son las ventajas de este método de trabajo?

El método conocido como pair pro­gra­m­mi­ng (en español, pro­gra­ma­ción en pareja) se utiliza pri­n­ci­pa­l­me­n­te en el de­sa­rro­llo ágil de software y, más co­n­cre­ta­me­n­te, en la pro­gra­ma­ción extrema (XP). El pair pro­gra­m­mi­ng es­pe­ci­fi­ca que siempre haya dos personas tra­ba­ja­n­do al mismo tiempo en el código y que, en la medida de lo posible, se sienten juntas. Una se encarga de escribir el código y la otra de su­pe­r­vi­sar­lo en tiempo real. Al mismo tiempo, están co­n­s­ta­n­te­me­n­te in­te­r­ca­m­bia­n­do im­pre­sio­nes: debaten problemas, en­cue­n­tran so­lu­cio­nes y de­sa­rro­llan ideas creativas.

Por lo general, a estos dos tra­ba­ja­do­res se les asignan di­fe­re­n­tes roles: el pro­gra­ma­dor al que se le ha asignado el rol de piloto se encarga de escribir el código. El pro­gra­ma­dor al que se le ha asignado el rol de copiloto se encarga de su­pe­r­vi­sar ese código. Una de las reglas del pair pro­gra­m­mi­ng establece que estos dos roles se in­te­r­ca­m­bien con re­gu­la­ri­dad (a in­te­r­va­los cortos). De esta manera se evita una posible brecha je­rá­r­qui­ca: se fomenta la igualdad entre ambos tra­ba­ja­do­res y se consigue un in­te­r­ca­m­bio fluido de roles.

Además, lo ideal es que el espacio de trabajo también se adapte a los re­qui­si­tos es­pe­cí­fi­cos del pair pro­gra­m­mi­ng. Cada tra­ba­ja­dor deberá tener su propio ratón, teclado y pantalla, en la que se mostrará siempre la misma in­fo­r­ma­ción que en la del compañero.

Algo menos habitual es el método de­no­mi­na­do remote pair pro­gra­m­mi­ng. En este caso, los pro­gra­ma­do­res no se sientan juntos, si no que están ubicados en lugares co­m­ple­ta­me­n­te di­fe­re­n­tes. Para que este método funcione, se debe contar con so­lu­cio­nes técnicas es­pe­cia­les. Aun a pesar de la distancia, los co­m­pa­ñe­ros deben tener una línea de co­mu­ni­ca­ción directa y deben poder acceder al código y vi­sua­li­zar las mo­di­fi­ca­cio­nes en tiempo real.

En la práctica, esta suele ser una co­la­bo­ra­ción entre dos de­sa­rro­lla­do­res con di­fe­re­n­tes grados de ex­pe­rie­n­cia: así, un tra­ba­ja­dor con más ex­pe­rie­n­cia puede tra­n­s­mi­tir sus co­no­ci­mie­n­tos a sus co­m­pa­ñe­ros más jóvenes di­re­c­ta­me­n­te a través de la práctica. Por su parte, es posible que a un tra­ba­ja­dor más joven se le ocurran otras ideas, quizá más in­no­va­do­ras, que puede aportar al proyecto.

Asimismo, una co­m­bi­na­ción de tra­ba­ja­do­res de di­fe­re­n­tes sectores también puede resultar bastante be­ne­fi­cio­sa: si un pro­gra­ma­dor de la vieja escuela colabora con un diseñador, la co­m­bi­na­ción de sus ex­pe­rie­n­cias puede ser de bastante ayuda tanto para uno como para otro.

El método de trabajo resulta de gran utilidad pri­n­ci­pa­l­me­n­te para proyectos grandes. El principio de “los cuatro ojos” es es­pe­cia­l­me­n­te eficaz cuando se tiene que trabajar con grandes ca­n­ti­da­des de código que, además, debe mo­di­fi­car­se con re­gu­la­ri­dad. Garantiza que en el texto de origen se va a in­tro­du­cir siempre la mejor versión posible de un fragmento, re­du­cié­n­do­se la cantidad de errores, de modo que no será necesario realizar tantos retoques a po­s­te­rio­ri. La su­pe­r­vi­sión posterior de códigos fuente muy largos requiere invertir demasiado tiempo y esfuerzo, por lo que lo más co­n­ve­nie­n­te es que estos códigos se es­ta­ble­z­can sin errores desde el principio en la medida de lo posible.

Sin embargo, no siempre es obli­ga­to­rio que esta co­la­bo­ra­ción sea entre los mismos co­m­pa­ñe­ros, incluso en el caso de un mismo proyecto. De hecho, puede resultar be­ne­fi­cio­so mezclar con re­gu­la­ri­dad estas parejas. De este modo, todos los miembros del equipo podrán tener una buena idea del texto de origen completo. Esto permite que el éxito del proyecto no dependa tanto de las di­fe­re­n­tes personas in­vo­lu­cra­das. Si una de ellas falla, no pone en peligro todo el proyecto, pues el resto puede compensar su ausencia.

El trabajo en pareja en el marco de un proyecto, tanto si se trata de la pro­gra­ma­ción como de otro pro­ce­di­mie­n­to, lleva consigo gran cantidad de ventajas. Por lo general, cuatro ojos ven mucho más que solo dos: con el método pair pro­gra­m­mi­ng se minimiza el riesgo de que se produzcan errores. Mientras una persona escribe el código, la otra lo visualiza y se concentra tan solo en la búsqueda de errores. Por lo general, nos resulta bastante co­m­pli­ca­do detectar los propios errores. Suelen ser nuestros co­m­pa­ñe­ros quienes los detectan con más rapidez.

Otra de las grandes ventajas derivadas de la co­mu­ni­ca­ción es el de­sa­rro­llo constante de la crea­ti­vi­dad: el constante in­te­r­ca­m­bio que se produce entre la pareja de pro­gra­ma­do­res hace que surjan ideas que quizá no se tendrían si el trabajo fuese in­di­vi­dual. La in­te­r­co­mu­ni­ca­ción también garantiza que los problemas se puedan so­lu­cio­nan mejor en menos tiempo. Pues, mientras una persona que trabaja sola puede sentirse sa­ti­s­fe­cha con la primera opción que mejor le parezca, las personas in­vo­lu­cra­das en el pair pro­gra­m­mi­ng siempre deben ju­s­ti­fi­car sus de­ci­sio­nes ante el resto. Es posible que estas tengan otra pe­r­ce­p­ción del problema y no estén sa­ti­s­fe­chas con la solución que se les propone. Esto genera un debate en el que suelen pre­se­n­tar­se nuevas ideas que derivan en un código mucho mejor.

Un buen código también es un código conciso: la ex­pe­rie­n­cia dicta que un texto de origen generado por pair pro­gra­m­mi­ng suele tener un diseño más corto y, por tanto, más eficiente. Esto permite un ahorro posterior en recursos en caso de ma­n­te­ni­mie­n­to y ada­p­ta­ción.

Como ya hemos me­n­cio­na­do, esta técnica también puede apro­ve­char­se para que los tra­ba­ja­do­res con más ex­pe­rie­n­cia compartan sus co­no­ci­mie­n­tos con sus co­m­pa­ñe­ros más jóvenes. De este modo, no solo se obtiene beneficio de la ventaja esencial del pair pro­gra­m­mi­ng, que es la ge­ne­ra­ción de un código de alta calidad, sino que también se puede utilizar si­mu­l­tá­nea­me­n­te para fines de formación.

Sin embargo, todo esto requiere mucho tiempo: dos pro­gra­ma­do­res juntos trabajan mucho más rápido que uno solo, pero no más que dos pro­gra­ma­do­res que trabajan por separado. Esto quiere decir que este método hace que los proyectos avancen más le­n­ta­me­n­te o que requieran más personal, lo cual aumenta a su vez los costes. Los pa­r­ti­da­rios del pair pro­gra­m­mi­ng estiman que estas horas ex­trao­r­di­na­rias se compensan pues el código generado contiene menos errores, está mejor es­tru­c­tu­ra­do en general y requiere mucho menos ma­n­te­ni­mie­n­to.

Otra posible de­s­ve­n­ta­ja es que el pair pro­gra­m­mi­ng es adecuado para la formación de equipos, pero solo si ambos co­m­pa­ñe­ros trabajan bien juntos. Al tratarse de una co­la­bo­ra­ción tan estrecha, es posible que los problemas que puedan tener entre ellos ra­le­n­ti­cen los re­su­l­ta­dos o acaben au­me­n­ta­n­do hasta algo mucho peor. Es por este motivo que la asi­g­na­ción de parejas en este método no puede rea­li­zar­se alea­to­ria­me­n­te. Lo ideal sería trabajar cada vez con un compañero diferente, pero esto solamente funciona bien si hay armonía en todo el equipo.