Programación por pares: un par que es mayor que la suma de sus partes. Es posible que haya oído hablar de la programación en pareja y se haya preguntado si valía la pena intentarlo en su lugar de trabajo. A primera vista, parece simple, pero dos desarrolladores sentados juntos no son todo lo que se necesita para lograr un emparejamiento productivo.

Los obstáculos logísticos y personales como la programación, la elección de herramientas y las distracciones pueden impedir que aproveche al máximo el emparejamiento. Pero las ventajas potenciales pueden hacer que valga la pena reconocer y superar estos desafíos.

¿Por qué emparejar?

¿Cómo podría ser más productivo tomar a dos programadores que anteriormente trabajaban en proyectos separados y hacer que trabajen juntos en un solo proyecto? ¿No tomará todo el doble de tiempo? Para un extraño, la idea de emparejar puede parecer contraproducente al principio, pero las ventajas se hacen evidentes cuando empiezas a pensar en por qué codificamos y qué estamos tratando de lograr.

La programación no se trata de producir la mayor cantidad de líneas de código en el menor tiempo posible, o incluso entregar la mayoría de las funciones dentro de plazos cada vez más ajustados. Puede tener ingenieros trabajando las veinticuatro horas del día introduciendo nuevas funciones en producción, pero ¿cuán productivos son realmente si esas funciones las desarrollan personas que trabajan de forma aislada de acuerdo con su propia comprensión única de la arquitectura general? Es probable que el código resultante esté plagado de deudas técnicas, como errores ocultos, problemas de rendimiento, sintaxis idiosincrásica y diseños ineficientes que pueden no usar los recursos de manera eficiente y pueden hacer que sea mucho más difícil y lento modificar el código cuando uno de esos Superficies de defectos.

Necesita que su código sea significativo y esté bien escrito para que funcione en conjunto sin problemas y pueda modificarse fácilmente. Lo necesita para encapsular la funcionalidad deseada para que su producto final se comporte correctamente y funcione como se espera. Necesita que sea resistente para que pueda soportar los cambios organizativos que son una parte natural del trabajo conjunto, así como los cambios ambientales y las nuevas expectativas de los clientes que pueden hacer que la solución viable de hoy en día quede obsoleta sin mucha advertencia.

Para hacerlo posible, los desarrolladores deben poder acordar claramente los requisitos fundamentales, ponerse al día rápidamente con cualquier tecnología nueva o establecida que pueda ser necesaria y concentrarse sin interrupciones para probar soluciones creativas y desarrollar un producto que valga la pena poner delante del cliente.

Estos son los desafíos del mundo real que la programación en pareja ayuda a abordar. Cuando dos desarrolladores trabajan juntos en pareja, la calidad del código que producen mejora junto con su comprensión compartida de cómo funciona. Esto facilita que la siguiente persona que lea el código lo recoja y lo modifique cuando sea necesario, y reduce el peligro de que la única persona del equipo que sabe cómo funciona parte del código pueda ganar la lotería y dejar el equipo. , llevándose ese precioso conocimiento con ellos.

El costo de tiempo en horas de trabajo míticas está lejos del 50% que puede parecer intuitivo si intenta equiparar el intrincado arte de la codificación con el trabajo repetitivo de la línea de montaje. Algunos estudios empíricos han llegado a la conclusión de que la programación en pares podría resultar en un aumento de aproximadamente un 15% en el tiempo que le toma a dos programadores realizar las mismas tareas si hubieran estado trabajando solos, pero el código resultante también será de una calidad mucho mayor, con aproximadamente un 15% menos de defectos observables arreglar. Combine esto con la propiedad compartida, un compromiso más profundo y una resolución de problemas más rápida que proviene de tener más de una mente involucrada en la resolución de un problema, y ​​está claro por qué la programación en pares es un enfoque popular.

¿Qué es exactamente el emparejamiento?

Entonces, ¿qué se necesita para que dos desarrolladores trabajen juntos para lograr las mejoras de productividad y calidad que provienen del emparejamiento? Es principalmente una cuestión de aprender a trabajar en colaboración, que no es necesariamente la forma en que la mayoría de nosotros aprendimos a codificar.

Por definición, la programación por pares no comienza hasta que dos personas trabajan juntas en una computadora. Pero, ¿cómo funciona eso en la práctica?

Dos personas …

El elemento fundamental de la programación de parejas es trabajar junto con su pareja. Cuando se acepta una tarea, es necesario compartirla entre las dos personas que trabajan en ella, y ambos deben estar completamente comprometidos con la tarea mientras se emparejan en ella. Eso significa que ambos deben comprender los requisitos de la misma manera y trabajar juntos para llegar a un entendimiento compartido de cómo quieren cumplirlos.

El emparejamiento ayuda a las personas a verbalizar mejor sus ideas y expectativas. La comprensión implícita que tiene en su cabeza cuando trabaja solo debe comunicarse para que tanto usted como su pareja sepan que están en la misma página. Ser lo más explícito posible sobre el trabajo y el enfoque desde el principio ayudará a que la experiencia de emparejamiento sea mucho más agradable. El emparejamiento implica hablar mucho, ya que es la mejor manera de mantener a dos mentes activamente involucradas en el problema al mismo tiempo.

Por esta razón, el emparejamiento a menudo se asocia con la escritura ágil de historias, en la que los requisitos para una función se definen en un lenguaje sencillo y coherente que puede ser entendido igualmente bien por el personal de Producto e Ingeniería con poco margen para la ambigüedad. A menudo, las parejas pedirán que las historias se deletreen en Pepinillo, que es una forma de utilizar frases comunes no técnicas que son fáciles de traducir a pruebas automatizadas, para que la pareja pueda verificar y demostrar que cada característica funciona como se esperaba.

Escribir en pepinillo significa tomar una característica y dividirla en una historia sobre un cliente que quiere algo que esta función le ofrecerá:

As <a customer of the product>
I want <something desirable>
So that <I can achieve a specific goal>

Entonces todo el criterios de aceptación están escritos en una sintaxis consistente, definiendo las permutaciones y escenarios anticipados asociados con esa historia:

Given <a customer in a particular state>
When <something specific happens>
Then <there is a specific outcome> Given <a customer in a particular state>
When <something different happens>
Then <there is a different specific outcome> etc.

Por supuesto, no es obligatorio usar esta redacción exacta, pero si los requisitos de una función no se pueden expresar de esta manera minimalista, es posible que las expectativas sean ambiguas. Esa es una posible señal de alerta que es más fácil de detectar para un par de programadores cuando comienzan a discutir lo que se necesita.

Tan pronto como una pareja acepte una historia en la que trabajar, deberían poder definir cómo sabrán que han terminado y cómo lo van a demostrar. A partir de ahí, pueden comenzar a descubrir juntos la mejor manera de abordar el trabajo.

De hecho, la pareja que trabaja en una función debe saber lo suficiente por adelantado como para comenzar escribiendo una prueba automatizada basada en el primer criterio de aceptación. antes de escribir cualquier código, asegurándose de que la nueva prueba falle y luego escribiendo solo el código suficiente para que la prueba pase antes de refactorizar y luego comenzar con el siguiente criterio de aceptación. Este enfoque se conoce como desarrollo impulsado por el comportamiento, y aunque no es parte de la definición de programación por pares, armoniza maravillosamente, junto con desarrollo basado en pruebas.

Trabajando juntos …

Cuando dos o más personas intentan trabajar juntas, lo primero que deben hacer es acordar un horario de trabajo. Realmente no es un emparejamiento si dos desarrolladores no están trabajando juntos al mismo tiempo. Debido a esto, es esencial que los desarrolladores que planean trabajar juntos coordinen sus horarios y se aseguren de que ambos acuerden un momento y lugar donde trabajarán.

Un error que he visto cometer parejas es tratar de maximizar el tiempo que trabajan juntos como pareja programando ocho horas completas juntos y, a veces, tratando de trabajar juntos más allá de eso. El emparejamiento es un trabajo intensivo que requiere un mayor nivel de concentración y participación. Es muy agotador intentar emparejar durante más de cinco o seis horas en un día, e incluso eso podría estirarlo incluso para los más resistentes. Al establecer un horario de emparejamiento, intente acordar un tiempo fijo y limitado que se ajuste a una jornada laboral típica de ocho horas, dejando tiempo para el almuerzo, el correo electrónico, las tareas personales, etc. Esas tareas personales son esenciales para nuestra jornada laboral. pero también son distracciones que no deben intentarse durante una sesión de emparejamiento.

También puede ser socialmente incómodo recordarle a su pareja cuando el tiempo de emparejamiento acordado ha llegado a su fin. Por esa razón, puede ser una buena idea configurar una alarma que les dé la noticia a ambos sin poner la carga sobre uno u otro.

El nivel de habilidad es otra área en la que las parejas pueden tener problemas. Es una suposición justa que, sin importar en qué esté trabajando, la persona con la que está trabajando tiene antecedentes, experiencia y comodidad con el tema diferentes. Reconocer eso desde el principio es importante, por lo que ninguno de ustedes sentirá la necesidad de tratar de ocultar ese hecho. Uno de los beneficios del emparejamiento es que trabajar juntos de forma natural mejora las habilidades de cualquiera que esté aprendiendo algo nuevo, ya sea un lenguaje de programación o un estilo de comunicación.

Sea amable si siente que es más hábil que su pareja. Trátelos de la manera en que le gustaría que lo trataran a medida que aprendió algo nuevo. Y recuerde que el objetivo no es solo hacer el trabajo, sino asegurarse de que ambos tengan el conocimiento y la propiedad suficientes del resultado final.

Con ese fin, es vital que cada programador tenga la oportunidad de sentarse al teclado y conducir mientras el otro observa y navega a través del código. El concepto de turnarse puede ser nuevo para cualquier persona cuya experiencia exclusiva como programador haya sido el trabajo en solitario, por lo que habrá una curva de aprendizaje a medida que se adapte a verbalizar sus intenciones al navegar o llevar a cabo las ideas de otra persona al conducir.

Un programador nuevo en el emparejamiento pero que se sienta cómodo con la tarea que tiene entre manos puede adoptar fácilmente el patrón de aferrarse al papel de conductor durante el mayor tiempo posible. De manera similar, si no está manejando con el teclado y no está tan familiarizado con el código, es fácil encontrar su mente vagando de regreso a su teléfono, su correo electrónico y sus otras tareas. Cuando eso sucede, termina con una persona codificando sola y la otra persona sentada en la misma habitación desplazándose por las redes sociales.

Una de las pistas de que una pareja podría tener problemas para turnarse es el silencio. El emparejamiento es un proceso ruidoso, que involucra muchas preguntas, comentarios, discusiones y colaboración. Cuando una pareja se encuentra pasando más de un minuto o dos sin decir una palabra, es probable que la pareja se haya detenido.

Una técnica útil que puede evitar que los pares caigan en este antipatrón es utilizar un Temporizador Pomodoro. Estos temporizadores mantendrán una cuenta regresiva de los segundos mientras trabaja en incrementos de 25 minutos, y luego le indicarán que tome un descanso de cinco minutos. Al cambiar los roles entre el conductor y el navegador durante estos descansos, una pareja puede evitar tener sesiones prolongadas con un solo conductor.

En una computadora ...

El emparejamiento solo funciona cuando dos personas dedican toda su atención a una sola computadora. Es mejor evitar la distracción de tener dos (o más) pantallas activas durante una sesión de emparejamiento. Incluso si una persona solo quiere buscar algunos ejemplos de código relevantes o verificar el estado de un proceso en segundo plano, es mejor hacerlo en una computadora compartida. Si se trata de una búsqueda, ambos desarrolladores pueden ver cómo se construye la búsqueda y qué resultados potenciales surgen. Si se trata de una actualización de estado, ninguno de los desarrolladores debe quedarse atrás.

Entonces, en cualquier par, ambos desarrolladores deben poder ver claramente la pantalla en la que están trabajando juntos. Una de las herramientas esenciales para el emparejamiento es un monitor lo suficientemente grande como para que ambos desarrolladores puedan ver lo que se está escribiendo con claridad. Dependiendo de las circunstancias, esto se puede lograr con una computadora portátil compartida si no le importa acurrucarse y usa una fuente lo suficientemente grande con un contraste adecuado. Una mejor solución es un monitor de escritorio o de pared más grande donde el código se puede mostrar y ver juntos de manera más cómoda.

El emparejamiento remoto es una opción muy viable en estos días. Hay una serie de excelentes soluciones que van desde Flojo or Meet herramientas para en toda regla entornos de desarrollo integrados y procesadores de texto que admiten pantalla compartida, conferencias telefónicas o ambas, lo que permite que dos personas en lados opuestos del escritorio o en lados opuestos del mundo trabajen juntas. Incluso si está en el asiento de al lado en una oficina abierta, compartir pantalla puede hacer que sea más fácil para ambos ver e interactuar con el código en la pantalla de manera más cómoda. (Solo te animo a que te mantengas concentrado y resistas la tentación de mostrar tu correo electrónico en una ventana separada mientras estás emparejando de forma remota. Es una falta de respeto, será obvio para la persona con la que estás emparejando y tu distracción te hará perder oportunidades de aprender juntos y producir resultados de calidad).

Si un par ubicado comparte una sola máquina, deberán llegar a un acuerdo sobre la configuración de sus computadoras, teclados, mouse, etc. compartidos. Ese teclado ergonómico con todas las macros de hardware personalizadas puede que no sea la mejor opción para compartir. . Pero si no le importa usar la misma computadora portátil o el mismo teclado y mouse, intercambiar roles de navegador a controlador en un par puede ser tan simple como cambiar de lugar.

Una solución popular y muy robusta es hacer un uso activo de un sistema de control de versiones como Git. Envíe su código con frecuencia a un repositorio compartido para que cada desarrollador pueda extraer la última versión y trabajar en su propio dispositivo cuando cambie de rol. El uso del control de versiones para manejar el intercambio en pares tiene la ventaja adicional de crear un historial más detallado de cambios de código para futuros registros y posibles reversiones. Si los registros de Git se abarrotan demasiado, siempre es posible volver atrás y aplastar esas confirmaciones adicionales en una única y más significativa antes de realizar una solicitud de extracción.

En un nivel superior, una vez que comience a emparejarse con otro desarrollador, notará algunas diferencias en la forma en que cada uno aborda sus tareas. Es posible que uno de ustedes conozca algunos atajos de teclado elegantes, tenga algunos alias especiales para comandos de shell comunes o prefiera usar un IDE específico debido a sus características únicas. En términos del código en sí, también es posible que cada uno tenga una comprensión implícita diferente sobre cómo se nombran las variables, cómo estructurar un mensaje de confirmación, cuándo usar comentarios, etc.

El emparejamiento es una oportunidad para hacer visibles estas variaciones inconscientes en la técnica para que todos puedan beneficiarse de la riqueza oculta de experiencia y conocimiento sobre cómo codificamos de manera más efectiva.

Cómo empezar a emparejar

A menudo hay un período de adaptación mientras se desarrolla la memoria muscular y se aprende a expresar ideas en voz alta que alguna vez fueron solo pensamientos en la parte posterior de la cabeza. También es necesario establecer una logística viable para permitir que dos personas trabajen juntas, lo que podría significar hacer ajustes en términos de horarios, ubicaciones y equipos. Y cuando tenga eso funcionando, puede intentar expandir el proceso a todo el equipo con mejoras como programación de la mafia para grupos, o pareja promiscua para darles a todos en el equipo la oportunidad de compartir todas las historias del equipo.

Hacer el esfuerzo para superar las etapas de aprendizaje generalmente se traduce en mejoras significativas, tanto para la calidad del código como para la felicidad y sostenibilidad de las personas que lo crean. Y si todo su equipo u organización adopta el emparejamiento, la curva de aprendizaje será aún más fácil para las personas nuevas, lo que mejorará el proceso de incorporación y ayudará a todos a ser más productivos.

Fuente: https://www.sitepoint.com/pair-programming-guide/?utm_source=rss