La programación por pares es una técnica que existe desde los primeros días del desarrollo de software y demostró ser una forma muy efectiva de mejorar la calidad del código, aumentar la productividad y aumentar la camaradería del equipo.

En pocas palabras, dos desarrolladores trabajan juntos en una estación de trabajo. Escriben código en tándem, con uno escribiendo (controlador) mientras que el otro revisa lo que han escrito (navegador).

En este artículo, exploraremos cómo la programación en pares puede brindar ventajas competitivas para los desarrolladores y organizaciones.

Permite difundir el conocimiento

El beneficio final de la programación en pareja es, sin duda, su capacidad para difundir el conocimiento entre los miembros del equipo.

Cuando estás programando solo, tomas microdecisiones sobre cómo abordar los problemas de manera efectiva. Tienes en cuenta lo que sabes del código base o piensas en conflictos particulares que pueden surgir ahora o en el futuro. Lo que sucede a continuación es que otro desarrollador en el equipo crea un componente relacionado con el suyo y le resulta difícil comprender por qué tomó esas decisiones, porque no ven de inmediato la lógica o las razones detrás.

Si presionó el código recientemente, puede abordar la situación en unos minutos con Slack, Teams o cualquier otra herramienta de mensajería. Por el contrario, una pieza de código antigua requiere que indagues en los tickets y te comprometas a recordar por qué elegiste ese camino. Por lo tanto, debe pasar por cambios de contexto y es posible que experimente dificultades para comunicarse con claridad o incluso ponerse nervioso al sentir una sensación de urgencia. Se vuelve aún peor cuando está en PTO o simplemente está enfermo y aún revisa sus notificaciones solo para que le digan que «lo que codificó el otro día no funcionará».

Sin una cultura sólida basada en la comunicación y la documentación, la programación en solitario puede llevar a los equipos a silos. Los silos reducen la velocidad y refuerzan el entorno competitivo dentro del equipo. La programación en parejas permite que los equipos compartan información de forma natural y difundan el conocimiento entre los miembros. Con sesiones centradas en la comunicación y objetivos compartidos, beneficia a los equipos, ya que pueden lograr la propiedad colectiva del código y disminuir en gran medida el factor bus.

Compartir mejores prácticas

Otra ventaja de la programación en pareja radica en cómo permite compartir las mejores prácticas con su equipo. Todos tienen su propio enfoque cuando se trata de codificación. No todos nuestros cerebros abordan los problemas de la misma manera y, en realidad, a menudo usamos estrategias que han producido resultados antes en primer lugar.

Después de pasar años programados, se adquieren algunos automatismos y la programación se vuelve repetitiva. En esta etapa, lo mejor que puedes hacer por tu equipo es compartir abiertamente esos automatismos. Esto no solo permite que los desarrolladores más jóvenes crezcan más rápido y los alientan a construir sus propios automatismos a largo plazo, sino que también garantiza que usted y su equipo estén todos en sintonía.

Por lo tanto, compartir las mejores prácticas a través de la programación en pares tiene mucho sentido, ya que puede demostrar el valor de cualquier automatismo que haya desarrollado en situaciones que lo requieran. Practicar sobre casos reales y concretos es la mejor manera de inculcar conocimientos en las personas. No puede esperar que los jóvenes mejoren por completo con solo compartirles su libro de jugadas de mejores prácticas de codificación. No puede esperar que las personas mayores escriban buenos tickets, elaboren sistemáticamente los problemas que encontraron o prueben su código de manera efectiva antes de pasar los tickets a la siguiente etapa simplemente diciéndoles que lo hagan. Necesita comunicarse activamente y mostrar con el ejemplo. La programación en pares es una herramienta útil para ese propósito.

Hace que bajen los defectos

La programación en pareja viene con un conjunto de mejores prácticas que incluyen quién hace qué en un momento dado. Tradicionalmente, los roles de pareja se dividen entre el conductor y el navegador. El primero es responsable de lograr los pequeños objetivos o pasos, uno por uno. Este último reflexiona sobre el panorama general y da las siguientes direcciones. Como navegador, puede ver mucho más allá de lo que el controlador está codificando actualmente. Haces uso del poder de tu tercer ojo para detectar obstáculos y conflictos con las otras piezas de código antes de que sucedan. Luego discuten juntos cuál podría ser el mejor enfoque o solución alternativa.

Como programador independiente, se corre el riesgo de perderse problemas potenciales enormes que ni siquiera espera, especialmente cuando no tiene en mente el panorama general del código base. Aquí es generalmente donde entra en juego la revisión del código. Después de que declaras que has terminado con la tarea, otro desarrollador mira tu código y genera advertencias al marcarlo en rojo y escribir comentarios, de forma muy similar a cómo el equipo legal revisa los acuerdos.

El revisor es, en última instancia, el responsable de permitir que su código pase a la siguiente etapa en su tablero de Scrum, por ejemplo, control de calidad, o pasar directamente a producción. El problema con la revisión de código es que ningún revisor es infalible. Revisar el código de otra persona requiere disciplina, cambiar de contexto y dedicar mucho tiempo a reflexionar sobre posibles problemas. Requiere mucho esfuerzo y un enfoque profundo. Por lo tanto, la mayoría de las veces, los revisores confían demasiado en el código del autor, lo que lleva a que los defectos no se detecten antes de llegar a la producción.

Refactorizar sobre la marcha

La deuda técnica es una batalla cuesta arriba constante para cualquier equipo de desarrollo. Para lidiar con eso, debe ser disciplinado como equipo y adoptar una cultura de revisiones periódicas. Si no lo hace, tarde o temprano su base de código se implosionará internamente y cualquier cambio requerirá muchos esfuerzos. Esa no es una tarea fácil cuando su equipo tiene plazos ajustados.

Afortunadamente, la programación en pares ayuda inherentemente a los desarrolladores a discutir y desafiar las soluciones a medida que surgen, lo que permite escribir menos líneas de código pero con una calidad general mucho mejor. Esto es lo que los ingenieros de la NASA concluyeron en 2001 después de realizar un experimento, utilizando Emacs y Ruby, para ver cómo la programación en pares mejoraba su productividad y les ayudaba a aumentar la entrega de valor empresarial. Compararon lo que produjo un desarrollador en solitario y un equipo de programación en pareja. Después de 6 semanas, el desarrollador en solitario había escrito 2144 líneas de código sin realizar pruebas. Después de 3 semanas, el equipo de programación de pares creó la misma funcionalidad con 866 líneas de código, incluidas 463 líneas de prueba. El autor atribuyó la reducción de líneas de código a la refactorización agresiva y la revisión continua del código inherente a la programación en pares.

Integración rápida

Un beneficio subestimado de la programación en pareja es cómo te permite incorporar a nuevos miembros del equipo rápidamente. Este es el trato, su empresa acaba de contratar a un nuevo ingeniero de software y se le ha asignado como su compañero de incorporación para ayudarlos mientras realizan sus procesos diarios, exploran su código base y se familiarizan con sus herramientas.

Al realizar sesiones frecuentes de programación en pareja con ellos desde el principio, puede inculcarles una visión clara sobre cómo se interconectan los componentes de su proyecto. También le permite profundizar en sus especificidades en lugar de dejar que exploren todo el código base solos. Además, es una oportunidad para que el recién llegado se familiarice rápidamente con su nuevo entorno, encuentre su lugar dentro del equipo y obtenga una idea de la cultura de la empresa. La programación en pareja reduce drásticamente el tiempo requerido antes de que los nuevos miembros del equipo se incorporen por completo.

Pero no solo beneficia al desarrollador que se incorpora. Como compañero de incorporación, también tiene la oportunidad de descubrir cualquier documentación interna faltante a medida que despliega sus explicaciones y da instrucciones. Esto sucede todo el tiempo. Eventualmente, la programación en pareja le permite asegurarse de que el ingeniero de software recién contratado sea realmente una buena opción para el equipo al definir objetivos a corto plazo y medir el éxito sobre la marcha.

Elimina las distracciones

Mantenerse enfocado todo el tiempo puede ser difícil cuando estás programando solo. Es especialmente cierto cuando te enfrentas a un problema complejo. Como ser humano curioso, con tal calificación altamente implícita en la naturaleza de su trabajo, puede tender a explorar diferentes rutas para resolver un problema. Ya sabes, solo para satisfacer esa picazón de curiosidad. Solo para que seleccione todo el código que escribió unas horas más tarde, presione eliminar y vuelva a una solución simple.

La programación en pareja los obliga a mantenerse enfocados juntos y evita que se queden atascados en detalles menores durante demasiado tiempo. Como pareja, se sienten responsables el uno del otro. De manera similar y cuando se emplea concienzudamente, la programación en pareja lo ayuda a mantenerse alejado de las notificaciones por correo electrónico, los mensajes telefónicos y otras distracciones. La contrapartida de ese enfoque profundo y la conversación constante es que te sientes más agotado al final del día que cuando estás programando solo. Solo asegúrate de tomar descansos regularmente.

Desarrolla la cohesión del equipo

El último beneficio es inherente a la naturaleza de la programación en pareja y la dinámica social que implica. Un equipo de desarrollo, como muchos otros, está sujeto a la competencia entre los miembros. La competencia puede ser saludable ya que permite a los desarrolladores establecer objetivos personales y sobresalir en su trabajo.

Sin embargo, se debe encontrar el equilibrio adecuado entre el trabajo en equipo y la competencia para garantizar la cohesión del equipo y evitar la desmotivación o incluso la rotación. Por ejemplo, los ingenieros de software que trabajan individualmente en la misma base de código pueden desarrollar un comportamiento tóxico cuando tropiezan con una implementación de una solución que difiere de lo que habrían hecho, convencidos de que saben más. Algunos programadores incluso aspiran a ser la persona a la que un equipo no puede prescindir.

La programación en pares, cuando se realiza de forma extensiva y con rotaciones frecuentes dentro de un equipo, le permite poner a todos los desarrolladores en la misma página. Al discutir y desafiar activamente las soluciones a los problemas con su equipo, los desarrolladores se vuelven responsables de todo el código base.