En otro artículo ya hemos hablado de las características que debe de tener un Lead Developer y cuales deberían ser sus responsabilidades, entre ellas invertir en la salud del proyecto, y para ello es importante apoyarse en prácticas como el Code Review.

Hay muchas visiones acerca de cómo llevar a cabo esta práctica, y en cada equipo de desarrollo se marcan unas reglas para que todos los miembros se sientan cómodos. Existen muchos artículos hablando de estas prácticas y sugiriendo ciertas ventajas que aportan cuando las añadimos a nuestra cultura de equipo.

Sin embargo, mi objetivo en este artículo es agrupar aquellas ventajas que son cercanas a mi visión de cómo debería ser un proceso de Code Review adecuado para nuestro equipo.

Motivos para implementar Code Review en tu equipo

Existen varios motivos por los que esta práctica es interesante, sin embargo, el motivo principal para empezar a implementar  Code Review es el de mejorar la calidad del código que desarrollamos y crear una cultura de equipo en la que todos los desarrolladores se sienten importantes. Vamos a analizar distintos motivos destacables:

• Compromiso y motivación: Al incluir Code Review en tu flujo de trabajo, los desarrolladores se comprometen más en realizar un código más limpio y a consolidar aspectos pendientes. Al saber que tu código va a ser revisado, se tiene más precaución, se mima más el código, se incrementa el compromiso con el proyecto y aumenta la motivación del desarrollador al ser gratificado por el resto de compañeros.  Todos necesitamos que nos digan “buen trabajo” y nos sintamos parte del equipo. También es importante asumir la crítica, dejar nuestro orgullo a un lado y que esta critica sea constructiva y positiva.
• Comunicación y conocimiento compartido: El mayor problema que encuentro en los equipos, especialmente en desarrollo, es la falta de comunicación. El proyecto es de todos y el código que implementamos es responsabilidad todos los miembros del equipo. Es por ello, que es importante que todo el equipo esté alineado sobre la funcionalidad que se añade o se modifica. Esta comunicación es positiva e integradora y une puentes entre el equipo. ¿No os ha pasado que dos desarrolladores han estado trabajando en la misma tarea?
• Aprendizaje: el Code Review ayuda a aumentar el nivel de calidad en toda la organización. Esto es debido a que los desarrolladores con menos experiencia pueden aprender rápidamente de aquellos con más experiencia en la tecnología que se esté utilizando. Probablemente un desarrollador con más experiencia ya haya tenido ciertos problemas por los que podrá guiarte por la mejor solución ¡Juntos somos más fuertes!
• Consistencia: Creo que es importante que el código sea consistente. Muchas veces se nota que parte del desarrollo se ha realizado por unas personas y otras, y cómo hemos comentado el código es propiedad y responsabilidad de todo el equipo, por lo que debería ser uniforme. Es importante establecer unas reglas de estilo, marcar unas estructura de carpetas y crear unas normas comunes. Esto facilita la lectura del código, prevenir errores y una mayor colaboración si un tercer desarrollador debe de ayudar en cierto proyecto pero ya conoce lo que se va a encontrar.

¿Cómo llevamos a cabo el Code Review?

Hemos hecho un recorrido por las razones principales para llevar a cabo esta práctica. Pero ahora nos preguntamos cómo incluimos esta práctica en nuestro flujo de trabajo.

Es importante encajarlo en el flujo de ramificación que estemos usando, ya sea gitflow, github flow o nuestra propia definición de ramas. La mayoría de servicios de repositorios de código (Github, Gitlab, Bitbucket) permiten crear pull requests / merge requests, y en esta funcionalidad nos vamos a apoyar para que este sea nuestro espacio común de discusión, donde se generará el debate y donde hablaremos de nuestro código.

Lo ideal es que cuando se termine una funcionalidad se abra un pull request contra la rama correspondiente, creando PR donde el resto de miembros del equipo puedan validar que los cambios añadidos son correctos y se puede mezclar en la rama principal. Es importante que se genere este debate y que al menos un revisor pueda darte feedback acerca de tus cambios. Veremos cuales son los puntos importantes que el revisor debe de tener en cuenta, pero lo mas importante es sentirse cómodo con el interfaz y descubrir el potencial que tiene para poder realizar comentarios sobre el código y que las conversaciones abiertas lleguen a buen puerto.

Una vez todo el equipo se ponga de acuerdo en aceptar estos cambios se podrá mezclar el pull request, dejando un histórico de que se ha mezclado, quienes han sido las personas involucradas y las decisiones que se han tomado totalmente documentadas en cada cambio.

Lo recomendable es que estos Code Review se comiencen a hacer una vez las comprobaciones automáticas (testing, codestyle, cobertura, análisis estático del código) se hayan completado con éxito.

¿Qué debemos de revisar al hacer un Code Review?

Los Code Review no entienden de rol en el equipo: ser la persona con más experiencia en el equipo no implica que tu código no necesite revisión. Incluso si el código es impecable, la revisión proporciona una oportunidad para la tutoría y la colaboración del resto del equipo. Todos podemos aportar en el proceso del Code Review y vamos a analizar cuales son los puntos principales que debiéramos de tener en cuenta a la hora de revisar el código de otro compañero:

• Propósito: Cada cambio en el repositorio debe tener una razón específica (nueva feature, refactor de código, corrección de errores, etc.). ¿El código enviado cumple realmente este propósito? ¿Está bien especificado el propósito?
• Legibilidad y estilo: ¿Se comprende el concepto en un tiempo razonable? ¿Es el flujo implementado sensato y los nombres de las variables y los métodos fueron fáciles de seguir? ¿Puedes hacer un seguimiento a través de múltiples archivos o funciones? ¿Es el código consistente con el proyecto en términos de estilo y convenciones de nombrado?
• Mantenibilidad: Revise las pruebas en sí mismas: ¿Se cubren casos interesantes? ¿Son legibles los tests? ¿Rompe este cambio la retro-compatibilidad? ¿Está la documentación actualizada?
• Seguridad: ¿Se implementa la autorización y la autenticación adecuadas ? ¿Existen ficheros de configuración donde no debieran? ¿Hay validación de los inputs?
• Arquitectura Software:  ¿Se cumple con la arquitectura software? ¿El código construido es flexible, escalable y reutilizable? ¿Cumple con las expectativas técnicas? ¿Cumple los principios SOLID? ¿Utiliza los patrones de diseño?
• Rendimiento:  ¿Se utiliza la cache de manera correcta? ¿Se usan los recursos adecuadamente? ¿Se evitan problemas de rendimiento?

Estas son algunas de las preguntas que podemos hacernos a la hora de revisar un pull request. Sin embargo estas preguntas van a cambiar en función del stack de tecnologías que usemos. Las preguntas son distintas si se analiza un pull request con cambios en la parte frontend o en el backend.

¿Como actuar frente al feedback del Code Review?

El propósito principal de la revisión del código es mejorar los cambios del autor; por lo tanto, dejemos a un lado el ego y tengamos la mente abierta para aceptar  las sugerencias y criticas del revisor. Se debe de tomar en serio cada comentario y hablar cara a cara si fuera necesario para debatir ciertos aspectos. Es importante que este proceso no sea un simple OK o KO.

Debemos de destacar tanto los puntos positivos como los puntos negativos del pull request. Se debe responder a cada comentario e intentar explicar por qué tomó ciertas decisiones, por qué existe alguna función, etc.  Es importante ser amable y que la critica sea constructiva. Los Code Review son una herramienta para construir y no para generar fricciones, abre tu mente para ver otros puntos de vista y utiliza esta práctica para que el equipo de desarrollo consiga un nivel mayor de madurez.

Conclusión

Hemos hecho un recorrido por  la visión principal de la práctica de Code Review. Hemos visto sus ventajas y cuál es la motivación para que sea algo necesario en nuestros equipo. Sin embargo cada equipo lo lleva acabo con unas normas  adaptadas a las necesidades de la empresa y el proyecto. Personalmente, creo que lo más importante es que todo el mundo se sienta cómodo con las normas que se establezcan y consiga que el equipo sea más maduro y crezca junto.

Para terminar, hace un tiempo lei sobre un ciclo de desarrollo muy interesante y que recomiendo que le deis una leída, por que me parece una buena aproximación para llevar a cabo: https://medium.com/finizens-engineering/nuestro-ciclo-de-desarrollo-to-do-fe7acdac8ce5

Otros enlaces interesantes:

https://www.atlassian.com/agile/software-development/code-reviews

https://medium.com/palantir/code-review-best-practices-19e02780015f