¿Qué pasa cuando pocas personas revisan la mayoría de los pull requests?

El proceso de revisión de los pull requests es quizás uno de los más costos para los equipos de desarrollo. Realizar estas revisiones claramente tiene muchas ventajas (lo recomendamos completamente!), pero necesitamos analizar si están teniendo un real impacto en nuestro proceso de desarrollo, y cómo podríamos aumentarlo. 

Nos preguntamos: ¿Influye la concentración de revisiones en la efectividad del proceso de revisión de código? Dicho de otra forma: si una sola persona o un grupo pequeño hace la mayoría de las revisiones en un equipo, ¿cómo afecta en el impacto de las revisiones?

En Teambit nos dedicamos a entender cómo mejorar la productividad y la calidad en los equipos de desarrollo. Por eso, buscamos responder este tipo de preguntas con datos antes que con intuiciones.

Midiendo la concentración de revisiones

Para responder a esta pregunta, analizamos cientos de miles de pull requests en diversas organizaciones y calculamos lo que llamamos "concentración ajustada de revisiones". Este indicador nos dice cuánto se desvía la carga de revisiones del equilibrio perfecto (donde todos revisan por igual) y cuánto trabajo recae en los "top reviewers" de cada equipo.

Básicamente, si un equipo tiene una concentración ajustada de 1, significa que todos revisan de manera equitativa. Si la concentración es 20, quiere decir que una persona está revisando 20 veces más de lo que sería "justo" dado el tamaño del equipo.

En nuestro estudio, encontramos valores que iban desde 6.4 hasta más de 93. Es decir, en algunos equipos, un solo desarrollador estaba haciendo casi todo el trabajo de revisión.

¿Esto afecta la efectividad de las revisiones?

Para medir la efectividad de las revisiones, nos enfocamos en el porcentaje de PRs revisados que no tuvieron impacto alguno en el código. Es decir, PRs en los que la revisión no generó cambios o mejoras significativas.

Encontramos que este porcentaje variaba desde 48% hasta 94%, lo que significa que en algunos equipos, la gran mayoría de las revisiones no estaban generando cambios sustanciales.

Combinando estos dos inputs: ¿hay correlacion?

Para ver si había una relación entre concentración y efectividad de revisión, usamos el coeficiente de correlación de Pearson.

El resultado fue un coeficiente alrededor de 0.33, lo que indica una correlación positiva. En otras palabras:

• En equipos donde la revisión de código está altamente concentrada en pocas personas, es más probable que muchas revisiones no tengan impacto.
• No es una regla absoluta (hay excepciones), pero la tendencia general es clara.

¿Por qué pasa esto?

‍Hay varias razones posibles:

1. Fatiga del revisor: Si una sola persona hace casi todas las revisiones, es probable que las haga rápido y superficialmente, simplemente por falta de tiempo.
2. Falta de diversidad de opiniones: Un solo revisor tiene una sola perspectiva. Cuando hay más revisores participando, es más probable que se detecten problemas y se aporten ideas valiosas.
3. Revisiones "de compromiso": A veces, el revisor principal puede aprobar PRs sin cambios solo para no convertirse en un cuello de botella.
   Esto pasa típicamente cuando solo el líder del equipo es el responsable de realizar todas las aprobaciones. Termina siendo una burocracia más que una revisión real.

¿Cómo mejorar la distribución de revisiones?

‍Si en tu equipo la revisión de código está hiperconcentrada en una o dos personas, podría ser momento de repensar la estrategia. Algunas ideas:

• Fomentar revisiones distribuidas: Incentivar que todos en el equipo revisen código regularmente.
• Automatizar lo obvio: Usar herramientas de linter y pruebas automáticas para reducir la carga de revisión en detalles menores.
• Definir estándares de revisión: Documentar qué se espera en una revisión de código para evitar revisiones superficiales.
• Rotar responsabilidades: Asegurar que diferentes miembros del equipo participen en revisiones críticas.

Reflexión final

‍Este estudio nos permitió validar algo que sospechábamos: la revisión de código no es solo cuestión de cantidad, sino de calidad y distribución equitativa. Si un solo desarrollador está cargando con la mayoría de las revisiones, es posible que el proceso no esté funcionando tan bien como parece. En Teambit tenemos un módulo dedicado justamente a monitorear la distribución de revisores y el impacto de las revisiones. Si te interesa conocer más no dudes en contactarnos.