Primer vistazo al Code Review y mejores prácticas

El code review hoy en día es un standard a nivel mundial en el campo del desarrollo de software o ingeniería de software. El mismo consiste en la tarea de hacer una revisión de código a un colega desarrollador para que una vez validado el mismo por una o varias personas (dependiendo el tamaño de equipo, la metodología planteada por el equipo o factores relacionados) ese código / merge request / pull request avance en el proceso de desarrollo para poder llegar a los siguientes pasos del mismo, ya sea QA, Staging, Production. Es una práctica que puede realizarse sea cual sea el tipo de software que se está desarrollando: un sistema operativo, una librería de uso común para Java, un sitio web, etc.

Al realizar estas revisiones, se busca que pasen varias cosas:

• Encontrar errores en una etapa temprana del desarrollo: siempre una vista externa da buena perspectiva para encontrar fallos que el otro desarrollador no encontró en el momento de escribirlo (solemos compenetrarnos demasiado a veces en lo que estamos haciendo y a veces podemos olvidarnos de detalles funcionales básicos o no tanto)
• Compartir conocimientos: Desde mi punto de vista y el de muchos colegas es genial poder tener la posibilidad de ver cómo otra persona plantea un problema para así poder cuestionarnos si nosotros lo hubiéramos hecho igual, peor o mejor y además uno tiene la chance de poder preguntar por las decisiones tomadas directamente a la persona que lo escribió.
• Distribuir conocimiento sobre la base de negocio entre los miembros del equipo: Algo fundamental en un equipo de desarrollo es poder estar relativamente tranquilo de que un feature desarrollado por alguien también es conocido por el resto del equipo. De esta forma, si por algún motivo la persona que escribió ese código no está disponible (ya sea por enfermedad, vacaciones, o la razón que fuere) cualquiera del equipo podría retomar ese feature sin mayores complicaciones. O al menos esto debería ser posible siempre y cuando la persona que hizo la revisión la haya hecho a conciencia y realizó las consultas necesarias para entender el trasfondo del problema y la implementación.

Muchos desarrolladores lamentablemente ven esta práctica como algo innecesario ya que algunos lo ven como una forma de “vigilar” lo que hace en el día a día en vez de verlo como una herramienta útil para poder progresar como desarrollador de software.
Aprender debería ser la primera meta en la implementación de esta práctica para desarrolladores y para empresas que estoy ayude a encontrar/evitar bugs lo más rápido posible.

Lo ideal al comenzar a realizar estas prácticas es dejar bien en claro entre todos los participantes tanto el objetivo de las mismas como a su vez la forma/manera de resaltar cosas en los mismos.

Por ejemplo:

• Si un compañero deja un comentario sobre algo que cree que podría mejorarse y no recibe respuesta puede llevar a que esta persona sienta que sus contribuciones o no son muy bien vistas por sus pares o bien la gente con la que trabaja no cree que la práctica sirva de nada. Por esto es importante mínimamente contestar los mensajes recibidos en la plataforma.
• Si hay una persona que considera que el cambio no está listo para mergearse y otras personas consideran que sí estaría bueno dedicarle algunos minutos (o el tiempo necesario dependiendo de la situación particular) para poder llegar a un consenso y que todos estén satisfechos.
• Para ahorrar tiempo valioso de nuestros compañeros lo ideal sería poder dejar toda la documentación que creamos relevante para que ellos puedan entender el objetivo de lo que quisimos lograr en el merge request, ya sea dejando ticket correspondiente, algun screenshot o bien comentarios varios detallando la toma de decisiones.
• Tener en cuenta que si previamente no hubo un acuerdo sobre el standard de codificación o manera de estructurar código no comiencen a dejar muchos comentarios diciendo cosas como “dejar un salto de línea”, “agregar espacio al cerrar la llave en esta función”, “reformatear el código”, etc.
• Lo que se puede hacer es plantear la necesidad/idea de comenzar a analizar esas cosas para ver qué opina el resto y analizar si lo implementan finalmente o les parece una pérdida de tiempo por algún motivo.

Otra práctica interesante en el tema es no solo dejar que las personas que mantienen el proyecto sean las únicas en opinar sobre el mismo. Por ejemplo, si estás desarrollando un backend con kotlin tranquilamente un desarrollador android podría sumarse al code review (tal vez sin posibilidad de que él sea el encargado de la aprobación del mismo, o si, depende de cada equipo) para analizar un poco el uso de ciertas herramientas comunes del lenguaje que se utilizan en todas las plataformas.
Incluso podría comentar/preguntar sobre decisiones si está más o menos en tema (ya sea que realizó trabajos previos en esa plataforma, realizó algún curso, o lo que fuere. Las posibilidades son infinitas).
Está practica puede ayudar a empoderar a miembros del equipo que desean aprender cosas nuevas (ya sean lenguajes, herramientas, librerías, o bien un cambio de plataforma)

En algunas herramientas es posible determinar/configurar code owners. Los code owners serían las personas encargadas de mantener ese código. Esto puede significar que son ellos los que deben tomar la decisión de aceptar/rechazar pull requests (más no necesariamente los únicos en dejar comentarios). Y si la herramienta no los deja configurar siempre puede haber algún acuerdo de palabra por fuera de la plataforma (lo cual no es muy común en equipos grandes para evitar problemas de merges aprobados por error o situaciones similares).

Si les interesa pueden encontrar muchísimos ejemplos de pull requests o merge requests en los diferentes repositorios más populares de la web, como GitHub (https://github.com/ ), GitLab (https://gitlab.com/), BitBucket (https://bitbucket.org), Assembla (https://www.assembla.com/home) por nombrar solo unos pocos.

La verdad es que es un tema muy interesante y extenso para charlar así que seguramente continúe escribiendo en el blog sobre maneras de implementarlo o buenas prácticas para mantener la cordura de todos los miembros del equipo de desarrollo.