Revisiones de código y relaciones de poder

Carles Climent
Jun 27, 2018 · 9 min read

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.

Conviene exponer el contexto en el que suscribo mis planteamientos antes de entrar en materia. Llevo varios años trabajando en equipos total o parcialmente distribuidos y con flexibilidad de horarios, donde la comunicación escrita y el trabajo asíncrono cobran mayor protagonismo que en equipos localizados con horario fijo. Además, en general participo en equipos pequeños o medianos, muy estables y orientados a producto, lo que permite alcanzar niveles de confianza mutua difícilmente alcanzables en equipos grandes o con mayor inestabilidad o rotación. Este factor, la confianza, será determinante a la hora de desarrollar la propuesta que redacto a continuación.

Por último, lo que se expone es un problema encontrado a lo largo de 15 años de profesión participando en distintos equipos y proyectos. Esa experiencia puede no representar la experiencia de quien lea el texto. Quien forme parte de equipos muy maduros habrá superado seguramente algunas, si no todas, las problemáticas aquí descritas.

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

En la cadena de montaje industrial, el ritmo de producción viene determinado por la velocidad a la que se mueve la cinta transportadora y limitado por la capacidad de trabajo de máquinas y operarios. En el fordismo del software, se instaura el muro Kanban (ideado por Toyota en su filosofía lean manufactoring) por el que transitarán las funcionalidades a producir a semejanza de la cinta transportadora. La especialización de roles típica del desarrollo industrial se dibuja generalmente con equipos de infraestructura, back, front y pruebas. Pero más allá de estos paralelismos, dado que el muro es una figuración y no es capaz de imponer por sí mismo un ritmo de trabajo, se recurre a la estrategia de limitar la cantidad máxima de tareas/historias en cada paso del proceso. Así, el límite actúa como un generador de presión que asegura cierta fluidez en el tránsito.

Y sin embargo, es común encontrar equipos que tienen problemas en ese tránsito sin ser plenamente conscientes de ello. Uno de esos eslabones problemáticos es la columna “Code Review”, donde las historias pasan gran parte del tiempo hasta que consiguen llegar a producción. ¿Dónde está la raíz del problema en esos casos?

En mi opinión hay dos problemas sustanciales que impiden, al menos por el momento, la total fordización del desarrollo de software. El primero es que el panel de desarrollo no fluye del mismo modo que en la cadena de montaje porque no es unidireccional. Las historias no fluyen de izquierda a derecha sin más, sino que sufren refinamientos y fricciones que las mueven hacia adelante y hacia atrás en los pasos de revisión y pruebas. Este ir y venir o quedarse atascadas genera ineficiencias por lo general poco advertidas en los equipos, quizá porque hemos llegado a asumir que es así como debe funcionar el proceso.

El segundo problema, que es en el que pretendo centrar este texto, es mucho más humano y quizá algo más filosófico. Trataré de ser breve.

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.

Otra de las particularidades del equipo, quizá derivada de la anterior, era el estancamiento habitual en la fase de revisión de las historias de uno de sus miembros en concreto. Se había generado una tensión tal que los demás correctores se negaban a corregir el código al compañero, y éste a su vez se resistía a ser corregido.

Tuve la oportunidad de mantener varias conversaciones con el programador díscolo, incluso de desplazarme físicamente para programar codo con codo con él. Creo que, a pesar de cierto comportamiento algo excéntrico, en el trato directo era una persona inteligente, razonable y con la que se podía argumentar. Y entonces, ¿por qué no encajaba en el proceso?. ¿Acaso era una persona con problemas de sociabilidad o de gestión emocional?. ¿Estaba roto mi compañero, era inservible para el trabajo en equipo?

Tratar de buscar causas en lo emocional era tentador pero me daba la sensación de estar quedándome en la superficie. Tardé en darme cuenta de que lo que molestaba a esa persona hasta el punto de romperse sus vínculos con los demás no era un problema de emocionalidad, sino provocado por las relaciones de poder establecidas durante la revisión de código. Él era incapaz de formar parte de ese juego de roles en el que uno se convertía en juez del otro, no era capaz de reconocer en los otros tal poder. Y contra ese poder de los compañeros que se erguían en una suerte de censores, él se rebelaba.

Si bien el caso anterior puede resultar exagerado, creo que no me equivoco si afirmo que la mayoría de equipos presentan fricciones similares, aunque más tamizadas o en menor intensidad. Creo que los roles que asumimos durante una revisión de código son similares, en fin, al de corrector y corregido. Que en este reparto de roles el revisor se ve provisto de instrumentos que le sitúan por encima del revisado, como la capacidad de bloqueo y el monopolio de la crítica. Y creo también, en fin, que este planteamiento de revisión es erróneo.

Así, no es difícil encontrar en cualquier equipo revisiones cargadas de adjetivos, connotaciones peyorativas, condescendencia y paternalismo. El revisor está en el estrado y el revisado en el banquillo, por lo que resulta natural que la comunicación se establezca en términos de dominio.

¿Como puede resultarnos gratificante este juego de sado-maso intelectual en el que el trabajo de una persona se somete al juicio de la otra? ¿No resultaría razonable establecer otras dinámicas que permitan llevar la comunicación en condiciones más respetuosas y constructivas? Y sin embargo, todos parecemos haber asumido el mecanismo de bloqueo, de rechazo o aceptación del código. Todos hemos aceptado que el guardián de la puerta es necesario.

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.

Ejemplificaré con un comentario extraído de un proyecto real:

This piece of code is tricky to me, I would rather use a service to do the stuff. The current implementation is so weird.

Eliminando la tercera oración, totalmente irrelevante, convirtiendo lo asertivo en percepciones subjetivas e invitando a que la otra persona exponga su punto de vista conseguimos un mensaje mucho más agradable para el receptor sin perder un gramo de la carga del mensaje.

I don’t fully understand this piece of code, I think I’d have used a service to do the stuff, so that [insert explanation here]. Maybe there is a reason that makes you prefer the other way?

Insistiendo en lo que afirmaba más arriba, no se trata de un problema de emocionalidad, sino de eliminar relaciones asimétricas durante la revisión y buscar fines más constructivos que el simple cambio en el código. El revisor no da por supuesto o critica, sino que propone y trata de comprender las decisiones del autor.

Cuando hay una conversación sobre el nombre de una variable mal escogido, el objetivo del revisor no debería limitarse a que el autor cambiase el nombre, sino averiguar cuáles fueron los motivos para que el autor escogiese ese mal nombre en primer término. ¿Puede deberse a dificultades con el inglés o con la terminología de ese dominio en concreto? ¿Tal vez faltaba el contexto adecuado a la hora de nombrar determinado concepto? ¿O quizá no hay un consenso claro sobre cómo se deben llamar las cosas? Encontrar la causa, buscar el alineamiento y aplicar soluciones a largo plazo y de forma colectiva es mucho más importante que impedir que una variable mal nombrada en un método más o menos irrelevante alcance producción.

En esencia, consiste en eliminar la verticalidad para conseguir una conversación simétrica. Los esfuerzos del revisor deben ir enfocados a explorar las decisiones del autor a través de la conversación. Y para que esta conversación se desarrolle al máximo, el entorno en el que se produce debe ser tan seguro y confortable como sea posible para todos los participantes.

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?.

Sabemos que el bloqueo de una historia en el kanban tiene un alto coste por la saturación del panel y por el incremento de carga cognitiva tanto en el revisor como en el revisado. Estar trabajando en una historia mientras en la otra se te solicitan más y más cambios rompe la concentración. También al contrario, tener varias revisiones abiertas y en proceso obliga a estar pendiente de ellas. Y sabiéndolo, no dudamos en bloquear incluso por diferencias puramente estéticas o de criterio.

En mi opinión, el bloqueo no debería ser sinónimo de “he solicitado cambios” sino de “estamos conversando”. Tan pronto como la conversación se estanca o las posiciones se enroncan debe llevarse esa conversación al vis-a-vis y resolverse en el momento, o moverse a una reunión aparte y dar salida al código. Cualquier discrepancia o desalineación, a no ser que resulte crítica para el funcionamiento normal del servicio, puede resolverse a posteriori sin bloquear el código.

Finalizo ya este texto demasiado largo en el que pretendo transmitir que las revisiones serían mucho más productivas si se plantean como ventanas a la colaboración y oportunidades para descubrir desalineamientos en el equipo, no como instrumentos de control. Si sustituimos la figura del revisor/censor por la de un facilitador cuyo principal cometido es iniciar la conversación, explorar el estado de los consensos y examinar la salud y la cohesión en el equipo.

Carles Climent

Written by

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade