Code Review; una colaboración entre dos

En los últimos 4 a 5 años me tocó hacer code review en todos los proyectos en los que participé dentro de Sodep, acumulando algunas experiencias que me gustaría compartir en este artículo. Code review es una práctica bastante común hoy en día, que estoy seguro muchos equipos lo hacen de alguna u otra forma, y quizás mis reflexiones puedan disparar algo en la mente del lector.

Code Review; no un espacio para debatir opiniones

Las opiniones como tenés que usar tabs de 4 espacios, punto y coma o sin punto y coma, comillas simples o dobles, etc., deben estar automatizadas y no deben ser apuntadas durante un code review. Existen distintas herramientas como Prettier que pueden formatear tu código durante el desarrollo con el estilo preferido por el team, antes de llegar al code review.

"Me recuerda cómo Steve Jobs solía usar la misma ropa todos los días porque tenía un millón de decisiones que tomar y no quería molestarse en tomar decisiones triviales como elegir ropa. Creo que Prettier es así."

- Anónimo sobre Prettier

Diría que se debe recurrir fuertemente a este tipo de herramientas, no solamente para estilos sino también validar buenas prácticas. Para esto último existen los linters que pueden analizar el código estáticamente y validar algunas prácticas como "const vs let" en JavaScript, o cantidad de argumentos en un constructor en Java.

Todo lo que se pueda automatizar, debería estar automatizado. Y los code review deberían ser espacios para apuntar algunas recomendaciones de buenas prácticas o patrones que se usan dentro de un code-base. Mantenibilidad y clean code deberían estar entre los objetivos primordiales.

Además de la automatización, los patrones/prácticas deberían también estar documentados en alguna guía dentro del repositorio, wiki, google doc, etc. Si el revisor encuentra que repite más de una vez una misma observación durante una revisión, esa observación debería documentarse.

Es un lugar de aprendizaje para todos

El revisor, debe asumir que la persona que envía su código para revisión sabe más que él, porque fue la persona que pasó más tiempo con la funcionalidad en su cabeza. Sé que existen muchas etiquetas hoy en día de desarrollador "junior", "senior", etc. pero eso debe dejarse de lado durante la revisión y asumir una actitud de aprendizaje. Quizás la persona descubrió un algoritmo, patrón o librería que el revisor no conocía.

Esto por supuesto también se aplica por el lado del revisado, que tiene que tener la mente abierta para aceptar soluciones alternativas que sean propuestas en la revisión. No debe tomar las observaciones como crítica personal sino como sugerencias para tomarlas y mejorar lo que ya escribió, o quizás no. El revisado es siempre el dueño, autor y apoderado de lo que se escribió.

"Recuerde, no soy un maestro; solo puedo ser una señal para un viajero que está perdido. Depende de usted decidir la dirección. Todo lo que puedo ofrecer es una experiencia, pero nunca una conclusión, por lo que incluso lo que he dicho debe ser examinado a fondo por usted."

- Bruce Lee

El revisado debe pedir feedback

El revisado debe pedir constantemente feedback. Si encuentra que el revisor le recomendó algún concepto de programación que no conocía, debería pedir al revisor alguna lectura recomendada sobre ese tema, para ahondar sobre el concepto. De esta manera estaría incrementando sus conocimientos para la próxima revisión, y para la vida.

Por otro lado si durante la implementación encontró algo sobre lo que no estaba seguro si hizo bien, debe dejar algún comentario en el código o en la herramienta usada para revisiones, y llamar la atención del revisor hacia ese punto del código. Eso no solo ayuda al revisor sino el feedback de retorno se hace más rápido.

El objetivo que el revisado debería tener en mente al enviar su código para revisión debe ser

✔️ Necesito ayuda para aportar algo más legible y limpio para el resto del equipo y de lo que mi futuro "yo" pueda estar orgulloso

A diferencia de

❌ Necesito que revises mi código o sino no puedo cerrar mi ticket y el project manager me va a retar

El revisado debe ayudar al revisor

El revisado a parte de apuntar a partes dudosas de su código, debe adoptar otras prácticas para facilitar el trabajo del revisor. Una de ellas es separar el código en varios commits, cada uno de ellos agrupando de forma semántica los cambios que se hicieron con buenos mensajes de commit, esto a diferencia de hacer un squash de todo. Por otro lado si se realiza formateo de código u otras actividades de refactor que no necesitan revisión, eso debería ir en un commit separado, entonces el revisor al leer el mensaje de ese commit sabe que puede pasarlo por alto.

Otra cosa que puede hacer el revisado es ir pidiendo opiniones antes de realizar la revisión formal, durante el desarrollo llamar a tu compañero a tu escritorio, o más adecuado a los tiempos actuales de distanciamiento, pasarle alguna rama de tu implementación parcial para que te de su feedback antes de llegar a la revisión final.

Sé amable

Lo cierto es que no siempre estamos en el humor ideal, cada uno tenemos nuestros problemas personales y días malos, y más en estos tiempos complicados de pandemia. Entonces la amabilidad debería estar siempre presente. Esto es lo que yo personalmente hasta ahora sigo trabajando en mejorar y no siempre me resulta sencillo.

Como hoy en día la mayor parte de nuestra comunicación es escrita, hay que ser conscientes de cómo nos expresamos al dar o pedir feedback, siendo que uno no le puede ver a la otra persona y muchas de las señales que enviamos al comunicarnos en persona, se pierden cuando la decimos por escrito. En este sentido algunas tonterías como usar muchos emoticones o enviar memes, ayudan mucho. Y más que nada pensar 2 o 3 veces antes de apretar el botón "Enviar", asegurándonos de que estamos usando un tono agradable.

Conclusiones

Durante una revisión de código:

• Enfocarse en mejorar y limpiar el código, no en opiniones de estilos, no en cerrar tickets
• Adoptar una actitud de aprendizaje
• Ayudarse mutuamente para una revisión agradable y fluida
• Ser amable

La revisión de código no es un esfuerzo solitario sino una colaboración entre más de una persona.