Otra razón para hacer Pair Programming

Unas semanas atrás nosotros (el equipo de desarrollo) estábamos pagando un poco de deuda técnica, antes de iniciar la sesión de codificación hicimos una pequeña reunión de planificación. Durante la reunión, les comunique a mis compañeros que realizaríamos las mejoras (refactoring) en parejas (pair programming).

Yo asigné las parejas y establecí un sistema de dos (2) rondas, durante cada ronda una pareja debía completar una tarea por cada integrante (desarrollador). Luego las parejas debían cambiar (de integrantes). Al final de la segunda ronda si algún desarrollador tenia trabajo pendiente, el (si todos hombres, aburrido), debería completar su trabajo trabajando solo. De esa manera durante el día de trabajo cada quien trabajaría con dos compañeros.

Luego de mie explicación de dos o tres minutos, alguien pregunto:
- ¿Por qué debemos hacer pair programming?
- Porque quiero forzar la nivelación y transferencia de conocimientos, contesté

Esa pregunta se quedó en mi cabeza todo el día, primero porque para mí era tan obvia la respuesta y también porque había muchas otras razones: 

• Aprender trucos del IDE
• Doble chequeo de refactoring (complejo y con posibilidad de introducir errores)
• Formación de lazos: el sentido de que estamos arreglando “nuestro” trabajo, no solo tratando con mi propia basura privada tirada en algún momento pasado
• Etc.

Resultados y Ventajas

• Pudimos reducir las violaciones reportadas por la herramienta de calidad en un 17%
• En el proceso aprendimos nuevos trucos del IDE de los compañeros, o los descubrimos por vagancia (tratando de cambiar más código en menos tiempo)
• Mejoramos archivos HTML al remover atributos no necesarios o elementos deprecados (por la especificación de HTML5)
• Discutimos el por qué las violaciones, seleccionadas manualmente, para solucionar eran importantes y como podrían afectarnos en el futuro
• Al final de la sesión todos acordamos en apartar un día de cada Sprint para pagar la deuda técnica vieja
• Ahora todos estamos más vigilantes, durante las revisiones de código, ante nuevas violaciones a los estándares de codificación 

Desventajas

• Gran parte del tiempo lo gastamos en tareas tediosas y manuales
• Para las 3 pm todos estábamos extenuados
• Conflictos de sincronización: por el hecho de haber distribuido las “violaciones” por tipo, y no por archivo o clase, hubo una alta tasa de conflictos

Retrospectiva

Puede ser mejor asignar el trabajo por archivo, o grupos de archivos. Así solo ocurrirán conflictos cuando la interfaz publica (de las clases) cambie.

También, una sesión de limpieza de código realizada por archivo o clase no es tan aburrida pues se manejan diferentes tipos de violaciones.