Revisiones de código y relaciones de poder

O de cómo aprovechar mejor los code reviews

Preámbulo, definición del contexto y advertencias

En los últimos tiempos, con mis compañeros y compañeras de trabajo, he insistido bastante en la necesidad de profundizar en el modo en que nos revisamos el código unos a otros. Si bien en el pasado no era algo a lo que concedía gran importancia, tras visitar bastantes equipos he creído reconocer una constante en la mayoría de ellos: la revisión de código es, en el mejor de los casos, un trance por lo general poco agradable para revisor y revisado que se lleva a cabo como un mal necesario en el camino del código a producción. En el peor, es una fuente de ineficiencias y conflictos que pueden minar la cohesión del equipo y la motivación de sus integrantes.

Pull Request, code review y fordismo

Tras la adopción masiva de Git y de los servicios basados en este sistema de control de versiones, el Pull Request se ha convertido en un mecanismo de sistematización del proceso de desarrollo. En mi opinión, no es sino otro intento de fordización de la industria del software tras el fracaso estrepitoso de las metodologías de desarrollo en cascada. Esta vez, sin embargo, las empresas parecen haber dado con una herramienta de sistematización o transformación fordiana mucho más compatible con el medio cambiante en el que se pretende instaurar que, además, resulta compatible con los gustos y pareceres del desarrollo ágil. Aún así, el proceso de revisión no está exento de problemas

Objetivos, asertividad y poder

Uno de los equipos en los que tuve la suerte de participar me dió muchas pistas a la hora de elaborar algunas conclusiones. Ese equipo tenía varias particularidades, entre las cuales estaba la forma de referirse a la revisión de código. Allí era habitual que alguien solicitase que “le corrigiesen el código”. Es decir, parecía que el objetivo de la revisión era depurar los defectos del código, y este proceso de corrección se llevaba a cabo mediante la asunción de roles en la figura del corrector y el corregido. No es extraño, por tanto, que el corrector se sumergiese en la interpretación de su papel hasta el punto de sentirse realmente en posesión de la verdad. Si bien la palabra “corregir” no está muy extendida, sí lo está esa misión que se supone a la revisión de código y un reparto de roles muy parecido.

Modulación del lenguaje y conversación simétrica

En primer lugar, para intentar subsanar estas relaciones de dominio y convertir las revisiones en un ejercicio más gratificate y constructivo, es necesario eliminar todo rastro de asertividad, emocionalidad y adjetivación en las revisiones. Descartar calificaciones improductivas e interpelar al autor del código dejando el comentario abierto al diálogo.

Bloqueos

Otro de los puntos calientes es la posibilidad de bloquear un Pull Request para que no pueda ser volcado a la rama principal. El bloqueo es el mecanismo habitual para solicitar cambios, y una forma natural de proteger el código existente, especialmente en proyectos open-source. Pero en un equipo pequeño y maduro, ¿tiene sentido mantener esas protecciones?. ¿Pensamos que el compañero o compañera va a realizar código que no debería ser mezclado?.