programación de pares
Programacion

¿Que es la programación de pares y cuales son sus beneficios?

Compártelo

Tengo un nuevo trabajo en el que hacemos las cosas un poco diferente de como lo hice en el pasado.

Honestamente, no puedo pensar en ninguna otra compañía de la que haya oído hablar que adopte rutinas y sistemáticamente paradigmas de programación de pares. Me imagino que la mayoría de las compañías para las que he trabajado en el pasado han contado con contables en el fondo diciendo algo como “No quiero pagar el doble por resolver un problema; ¿Por qué en el mundo dos personas trabajan en exactamente lo mismo a la vez? ”

La adopción completa de este nuevo lugar de trabajo de la programación de pares es una diferencia visible que realmente se desvía de la norma en la escena laboral en mi área.

A los efectos de esta historia, defino la programación de pares como teniendo dos personas trabajando en la misma computadora resolviendo el mismo problema de codificación al mismo tiempo.

¡No entres en pánico! Mientras que el aspecto de “hablar con otro ser humano durante la mayor parte del día” puede sonar aterrador, en realidad no lo es. En mi experiencia, tener dos personas trabajando en una codificación realmente resulta beneficiosa al final.

Por supuesto, los miembros más introvertidos de los lectores de este blog (es decir, la mayoría de nosotros) probablemente se aterroricen un poco por esta perspectiva. Pero lo prometo, la programación de pares lo vale. El valor que proviene de tener un par para programar realmente ha cambiado la forma en que veo el código de alta calidad.

La programación en pares ha hecho que mi código sea más fácil de leer, redujo el tamaño general de mis archivos de clase y, en general, simplificó el código que solía ser mucho más complejo.

Después de haber aprendido las fortalezas de la programación de pares, te recomiendo encarecidamente que abras la práctica con tus gerentes y tu equipo. El valor de tener a alguien más trabajando directamente con usted en su código no puede exagerarse. Claro, hay algunos inconvenientes; sin embargo, en mi experiencia, son ampliamente superados por la programación de pares positivos netos.

Entonces, ¿qué es lo que diferencia a la programación de pares de volar solo?

La configuración física

Para que la programación de los pares funcione correctamente, el primer factor y el más importante es la configuración del hardware. Los pares deben, literalmente, compartir una computadora.

La forma en que hacemos que esto funcione es con dos pantallas muy grandes y de muy alta resolución, dos teclados y dos ratones. Los monitores se configuran en modo espejo y cada persona obtiene el control de un teclado y un mouse.

De esta forma, podemos saltar fácilmente ya que tenemos ideas que queremos convertir en código, sin tener que decir: “Oye, ¿puedo tener el teclado por un minuto?”

Es realmente la codificación en paralelo. Y tiene todo tipo de beneficios.

La programación de pares tiene una cadencia

Si entras en mi oficina y no tardas mucho en detenerte y te das cuenta de lo que está sucediendo realmente, la programación de los pares probablemente parezca un montón de programadores agrupados en parejas, con cada par compartiendo una computadora.

Puede que no se vea muy diferente a las personas que programan por sí mismas, o como cualquier otra persona que trabaje en el mismo escritorio.

Pero la programación de pares tiene un patrón y una cadencia: no es solo programación individual dos veces. Si así fuera, se perdería todo el valor de la programación como un par y el emparejamiento no sería una inversión; sería solo un costo agregado y un desperdicio del tiempo de un programador.

El patrón general de un par se basa en gran medida en una buena rutina de prueba. Y depende del par para garantizar que las pruebas estén bien escritas.

La programación de pares agrega un valor significativo al aumentar drásticamente la calidad de la salida que generamos. La cantidad de defectos en el código que creamos es muy pequeña en comparación con los trabajos anteriores en los que he trabajado. Y rara vez implementamos la lógica empresarial equivocada porque siempre tenemos que justificar nuestra lógica con la persona que está sentada a nuestro lado.

Hay ciertos patrones que los programadores solo pueden lograr como programadores de pares, y últimamente me he encontrado anhelando un segundo par de ojos cada vez que escribo código, no solo en el trabajo. (La desafortunada realidad es que tengo que programar por mi cuenta en casa. Pero está bien, me las arreglo).

La rutina que seguimos como pareja se ve así:

Escriba una prueba funcional o de integración, escriba una prueba unitaria, escriba el código para pasar la prueba, refactorice el código, revise el código, controle el código.

Eso probablemente parece bastante familiar, pero cada uno de esos pasos ocurre con dos personas en el teclado (s). Y la parte de prueba realmente tiene una sensación diferente, que trataré con más detalle un poco más adelante.

Lo único que hace que programar un par sea una píldora difícil de tragar es el costo de contabilidad asociado. Los beneficios no tangibles de la programación de pares superan drásticamente el costo de pagarle a dos desarrolladores para trabajar en el mismo problema, pero sin apreciar cómo la programación de pares puede beneficiar enormemente los resultados de un proyecto, los contadores lo verán doblemente caro.

Revisión de código instantánea

La revisión del código en tiempo real es uno de los beneficios más obvios para emparejar la programación.

Cuando hay dos personas involucradas activamente con las líneas de código en la pantalla, quedan atrapados más errores tipográficos y lógicos.

Y si el código que se escribe no tiene sentido para el dominio del problema en el que se usa, los pares tienen el doble de posibilidades de darse cuenta de que la dirección actual del código debe cambiar.

De hecho, hace poco estuve trabajando con mi pareja en una de nuestras tarjetas. Estuvimos cerca de una hora cuando dijo algo así como: “Creo que otro equipo ya resolvió este problema”.

Resulta que tenía razón: un equipo diferente ya había escrito una biblioteca para hacer lo que estábamos tratando de hacer. Lo cual probablemente nos habría tomado el resto del día para hacer. Así que ahorramos un montón de tiempo teniendo dos cabezas resolviendo problemas.

La programación en pares es el próximo paso evolutivo en la revisión del código. Si no está haciendo ningún tipo de revisión de código mientras trabaja en el código, debería hacerlo. Casi todos los beneficios de salida creativos de revisión; este blog, por ejemplo, tiene editores, todo un equipo de ellos.

La revisión de códigos es como tener un equipo editorial: te ayuda a detectar cosas que de otra forma pasarías por alto. Porque somos humanos y los humanos extrañamos cosas.

La programación de par proporciona una revisión en tiempo real de lo que está trabajando. Lo que significa que es mucho más probable que haya dos compradores diferentes por cada línea de código.

Si crees que cada línea de código es una decisión comercial, tener dos personas que tomen esa decisión juntas simplemente tiene más sentido.

Emparejamiento y TDD

No voy a profundizar en los principios de Test Driven Development (TDD) en esta publicación porque es un tema que merece su propia consideración.

Basta con decir que TDD significa que siempre tiene pruebas que no pasan, y luego implementa el código de producción para que pasen. Es de donde viene el término red-> green-> refactor.

Sin embargo, la programación de pares juega un papel crucial en el éxito de una TDD completa. Es la mejor manera de asegurarse de que sus pruebas estén probando lo correcto, porque su pareja trabaja para asegurarse de que la lógica comercial que se está probando sea la correcta. Una prueba solo tiene valor si prueba las cosas correctas.

En la configuración de programación de nuestro par, una persona escribe la prueba automática de la unidad y la otra persona escribe el código de producción para pasar la prueba.

Emparejamiento Malvado

Cuando me uní a mi equipo actual, nunca había escuchado hablar del concepto de emparejamiento del mal; de hecho, era tan nuevo en la programación de pares que el patrón del emparejamiento del mal era completamente extraño para mí. Y luego tengo que ser malvado. Y fue tan divertido.

Definido de manera sucinta, el emparejamiento maligno es la práctica de escribir la cantidad más pequeña de código posible para pasar una prueba unitaria, por lo tanto, prueba incorrecta o incompleta.

Incluso más allá de lo divertido que es, el emparejamiento malvado tiene una función realmente importante. Nos obliga a asegurarnos de que nuestras pruebas sean tan buenas como nuestro código de producción. Porque sin buenas pruebas, realmente no se puede tener un buen código de producción.

La mejor forma en que describo esta situación es proporcionar un ejemplo artificial de algún código de prueba y la forma diabólica de hacerlo pasar. Gracias a Microsoft por darme una base de referencia decente para trabajar.

Puedes ver la malvada forma de pasar esta prueba unitaria en mi esencia aquí:

using System;

namespace Prime.Services
{
public class PrimeService
{
public bool IsPrime(int candidate)
{
return candidate != 1;
}
}
}
view rawPrimeService.cs hosted with ❤ by GitHub
using Xunit;
using Prime.Services;

namespace Prime.UnitTests.Services
{
public class PrimeService_IsPrimeShould
{
private readonly PrimeService _primeService;

public PrimeService_IsPrimeShould()
{
_primeService = new PrimeService();
}

[Fact] public void ReturnFalseGivenValueOf1()
{
var result = _primeService.IsPrime(1);

Assert.False(result, $”1 should not be prime”);
}
}

Es obvio que una prueba para números primos no debería fallar si un valor es distinto de uno. Sin embargo, eso es exactamente lo que hice, y la prueba de unidad pasa.

Así es como veo el mal emparejamiento: la persona que implementa el código para resolver la prueba debe escribir el menor código posible para pasar la prueba.

Usamos esta práctica para exponer casos límite u otros escenarios que la prueba no haya cubierto inicialmente. (También tiene el importante beneficio adicional de que la persona que realiza la implementación cacaree malignamente cuando pasan una prueba de una manera horrible).

Compartiendo la gran imagen

Como regla general, los estudios de neurociencia sugieren que nuestra memoria de trabajo puede contener como máximo siete elementos a la vez.

No sé acerca de sus proyectos de programación, pero en el mío, casi siempre hay más de siete conceptos para hacer un seguimiento mientras estoy resolviendo problemas.

Sin embargo, si agrega un segundo cerebro, eso duplica la cantidad de cosas que podemos seguir a la vez. Entonces ahora 14 ideas pueden estar revoloteando en su memoria de trabajo combinada.

En general, es una buena idea que una persona piense en el problema más inmediato, mientras que la otra persona trata de tener en cuenta el panorama general y la arquitectura general del sistema. A menudo estos pensamientos se superponen.

A veces entran en conflicto el uno con el otro, y ahí es cuando tienes que tener una conversación sobre la mejor ruta hacia adelante.

Por lo general, esta conversación parece algo similar a la que tuve recientemente sobre nuestros patrones de almacenamiento de datos. No estábamos seguros de si deberíamos usar ORM o simplemente SQL, así que hablamos de ello por un tiempo y finalmente decidimos que SQL simple tenía más sentido. Esto fue a pesar del hecho de que estábamos usando ORM para el almacenamiento de datos en ese momento.

Estaba escribiendo un código ORM, y mi pareja estaba pensando en cómo resolver el problema usando SQL en su lugar. El SQL tiene más sentido. Entonces, eso es hacia lo que cambiamos de dirección. En última instancia, nuestro código ha tenido mucha menos complejidad y nos es más fácil explicarlo entre nosotros, por lo que fue una buena victoria.

Par Soberanía

Como regla general, nuestros equipos constan de suficientes personas para formar al menos dos pares de programadores al mismo tiempo. Y trabajamos muy cerca el uno del otro.

En general, todos en el equipo trabajan en parejas. En ocasiones, podemos trabajar solos, pero valoramos la programación de pares como una práctica y nos esforzamos por incorporar siempre el par trabajando en nuestra rutina diaria.

Cambiamos los pares con frecuencia para que todos podamos trabajar entre nosotros de forma rutinaria. Esto también nos ayuda a crear código que ha sido escrito por un equipo y no solo por una (o dos) personas.

Una cosa que realmente ayuda a este diseño es que creemos firmemente en la soberanía de los pares. Como un par trabaja diligentemente para resolver un problema determinado, otros pares no interrumpen ese par con sugerencias como “podría ser mejor si” o cualquier otra cosa que rompa el límite del par. Mientras estás en un par, tu pareja gobierna el código en el que estás trabajando, sin excepción.

Esto nos ayuda a mantenernos enfocados en el problema que estamos resolviendo como pareja y no preocuparnos por cuáles son los problemas de la otra pareja. Lo veremos en la revisión del código, por lo que no hay duda de que perderemos la pista del conocimiento comercial de un par con el que no estamos trabajando.

Lidiar con la distracción

En un entorno en el que todo tu equipo comparte un espacio y no hay paredes de cubículos (o paredes reales) que te separen, es fácil distraerte y alejarte de las tangentes que no tienen nada que ver con el problema que estás resolviendo. o incluso con trabajo en absoluto.

En estos casos, mi equipo tiene una palabra de seguridad que usamos. Si alguien en nuestro equipo dice la palabra “canela”, significa que hemos notado que hemos estado fuera de pista como equipo durante varios minutos y que la distracción se ha vuelto improductiva en general.

Las distracciones son buenas; ayudan con la construcción de equipos y la camaradería general. Pero a veces se les va de las manos, así que es por eso que podemos decir “canela”, como un suave recordatorio de que es hora de volver al trabajo.

Este tipo de herramienta de comunicación es importante para cualquier diseño de equipo. Pero con la programación de pares, casi siempre ocurre una conversación. Entonces, necesitamos una manera de garantizar que esas conversaciones no nos distraigan de nuestros objetivos de solución de problemas.

La comunidad no es una distracción

Aunque a veces podemos desviarnos del curso y dejar de hablar sobre los problemas que nuestro equipo está resolviendo, la comunicación al aire libre de nuestro equipo construye una mejor comunicación en general y actúa como una red de seguridad para nuestro equipo. Nos ayuda a trabajar mejor juntos y resolver problemas de manera más consistente como grupo.

Los introvertidos también lo disfrutan

Una de las grandes diferencias que notará entre la programación de pares y la programación en solitario es el enfoque global para mantener a las personas involucradas entre sí. Es casi imposible encontrar una habitación oscura en la esquina o un cubículo y esconderse del resto del equipo porque todos notamos -y nos preocupamos- cuando uno de los miembros de nuestro equipo no está disponible para el emparejamiento.

No es que condenemos la práctica de tomar un descanso; todos entendemos que somos personas introvertidas y que a veces necesitamos tranquilidad. Pero nos gusta trabajar juntos. Y todos entendemos que resolver un problema solo puede ser muy aislado y desmoralizador. Así que siempre nos ayudamos unos a otros de cualquier forma que podamos.

Comunicación

Para asegurarnos de que no terminamos con silos de conocimiento donde un par tiene toda la información sobre una solución dada, también hacemos algo rutinario llamado cambio de pares. Ya sea dentro de una caja de tiempo o en puntos de ruptura lógicos (dependiendo de lo que el equipo decida hacer), regularmente haremos que una persona permanezca en una máquina, mientras que la otra irá a un par diferente.

Esta rotación ayuda a garantizar que todo el equipo tenga un contexto para toda la arquitectura de la solución, y rompe dramáticamente los silos de conocimiento. Es la mejor manera que he visto de lidiar con el problema de que una persona se convierta en el único experto en materia en un dominio.

Compare esto con la programación individual, donde podría pasar un día (o más) resolviendo un problema y no hablar realmente con nadie sobre el problema con el que está involucrado.

Incluso si se toma el tiempo para hacer una revisión de código post hoc del código que ha escrito, el resto del equipo pierde el contexto de dominio problemático que gana en el momento, que no se puede recuperar sin un código realmente complicado.

Si va a tener una revisión del código para cubrir todo lo que aprendió para resolver un problema, probablemente le tome tanto tiempo como resolver el problema en primer lugar. Y la mayoría de los lugares no estarán dispuestos a revisar el código por tanto tiempo.

El cambio

Entonces, ¿qué sucede en situaciones en las que está en un par y su conocimiento combinado del dominio del problema no es suficiente para superar la tarea actual?

Hay una herramienta más que tenemos en nuestro toolbelt, y se llama “la vuelta”. Entonces es cuando literalmente decimos la frase “cambio” para nuestro equipo, y todos se alejan de su escritorio y se dirigen al equipo para discutir el problema que tienen entre manos. .

Por lo general, se requieren menos de cinco minutos de discusión para llegar a un acuerdo razonable como equipo sobre cómo resolver el problema. En ocasiones, el tiempo de respuesta puede llevar un poco más de tiempo para encontrar el camino correcto, pero por lo general es bastante rápido.

El otro día, el tema de un cambio fue simplemente verificar que queríamos llamar a nuestra tabla de base de datos “Chewbacca”. No podía recordar, así que le pregunté al equipo. Tardó unos quince segundos. Pero esos quince segundos nos ahorraron una tonelada de disonancia cognitiva más tarde si en lugar de eso decidiera llamarlo “HanSolo”. (Obviamente, los nombres se cambian para proteger la base de código, que no puedo divulgar)

Independientemente del momento, siempre que todo el equipo comprenda la dirección que estamos tomando con nuestro código, se cumple el objetivo principal del cambio.

La programación de pares es divertida

Más que nada, lo que obtienes como programador de pares es una sensación de diversión con otra persona a la que le encanta programar tanto como a ti.

He trabajado en lugares anteriores donde me puse los auriculares, arranqué el código durante ocho horas al día y luego me fui a casa. Es el sueño de un introvertido, pero también puede ser aislante y frustrante.

La programación de pares elimina completamente el aislamiento que crean nuestros trabajos de programación, a propósito. Alienta a la comunidad y enriquece nuestra experiencia general del equipo.

Compártelo

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *