Change Surfers

Revisión de código: proceso y empatía

Una buena revisión de código varía en función de muchos factores como pueden ser el número de personas que componen el equipo, las herramientas que utilicen y la experiencia del mismo.

Para explicar cómo debe llevarse a cabo una correcta revisión de código emplearemos un supuesto práctico. Es el siguiente:

Érase una vez…

Una desarrolladora que tenía terminada una feature y quería añadirla al repositorio de entrega generando una Pull Request (en adelante “PR”) con sus modificaciones, en la que incluyó a sus compañeros para que revisen su código. Esto se debe hacer antes de subir la feature a develop, una rama de release, master o cualquier otra rama, según se estipule en el acuerdo y en las prácticas del proyecto. Además, con el objetivo de facilitar el trabajo de los revisores, la desarrolladora escribió una descripción de la PR exponiendo los siguientes puntos:

     – Cuáles son los cambios que se incluyen.
     – Un listado describiendo los prerrequisitos necesarios del proyecto antes de poder subir el código.
     – Cómo usar la feature desarrollada (por ejemplo, un gif).
     – Si existen cambios de diseño, una descripción de cuáles son e incluir una comparativa del antes y  el después.
     – Cualquier otro tema a tener en cuenta para sus compañeros.

Hecho esto, los desarrolladores marcaron si los cambios propuestos eran válidos para ser entregados a los clientes. Lo más deseable es que sus compañeros revisen esa tarea tan pronto como puedan con el fin de que, en caso de que la desarrolladora tenga que ejecutar algún cambio, pueda hacerlo antes de pasar a otra tarea. En este cuento vamos a imaginar que la revisión de la PR es rápida y que se piden una serie de cambios. 

El feedback que envían los revisores debe indicar claramente qué se debería cambiar y, sobre todo, el porqué. Cuando estén explicando el motivo de los cambios es recomendable que añadan información de guías, artículos y documentación que proporcionen información más detallada de por qué se deben realizar las modificaciones. De esta manera, todos pueden aprender de los errores. Naturalmente, esta crítica siempre debe ser constructiva para que la otra persona aprenda y que, tanto el código como el producto, resulten lo mejor posibles. 

En las PR solo se deberían mencionar problemas sobre la funcionalidad, excluyendo comentarios o tareas sobre las preferencias de cada individuo. Un ejemplo de mal comentario sería este: “Usa un switch case en lugar de if else, que lo prefiero…” Con el fin de evitar este tipo de situaciones,  el equipo debería generar un documento de buenas prácticas y algún Linter o similar para controlar el estilo, de tal forma que el código a revisar siempre sea homogéneo. Así, tanto la desarrolladora de la feature como los revisores se pueden centrar en la funcionalidad y en la calidad del código.

En un proceso ideal los prerrequisitos (el código debe tener un porcentaje de cobertura de tests del x%, se debe usar este paradigma o este otro…) son un paso previo a la PR. No obstante, si a alguien se le olvida, se lo recordaremos para que lo tenga en cuenta en el futuro.

Una vez se han llevado a cabo todas estas tareas, nuestra desarrolladora podrá subir su feature corregida y tanto ella como sus compañeros serán mucho más felices y comerán perdices.

Tanto la desarrolladora que está siendo revisada, como los revisores, son personas y a todos nos gusta que nos traten bien. Humanicemos las Pull Requests y convirtámoslas en un paso que siempre sea positivo tanto técnica como personalmente.