El otro día me encontré con este tweet que me generó bastantes preguntas:

Siempre ha existido el debate de si hacer revisiones de código (code reviews) es realmente útil, cada vez que se agrega una nueva funcionalidad o se arregla un bug.

¿Son realmente una pérdida de tiempo como algunos creen, o esconden un valor que no todos logran apreciar?

Primero hablemos de la teoría:

Hacer "Code review" (revisiones de código) es una práctica donde otros desarrolladores revisan tu código antes de que este se vaya a mezclar (se haga merge) con el código principal.

La idea es identificar errores, mejorar la calidad del código y compartir conocimientos entre el equipo.

Siguiendo esta teoría podemos tener conseguir estos beneficios:

1. Calidad y mejores prácticas: Está el argumento de que los code reviews mejoran significativamente la calidad del código. Permiten identificar errores que a veces pasan desapercibidos para el autor del código.
2. Confianza y colaboración: Pueden fortalecer la confianza dentro del equipo. Facilitan la colaboración, el intercambio de conocimientos y promueven un ambiente de aprendizaje continuo.
3. Inversión en el futuro: Si bien pueden tomar tiempo, hacer code reviews es una inversión. Un código más limpio y mantenible reduce los costos a largo plazo asociados con la corrección de errores y la implementación de nuevas características.

Y por otra parte, tenemos estas desventajas:

1. Productividad vs. Calidad: Como dice Erik Bernhardsson en su tweet, representan un impuesto a la productividad. La idea es que el tiempo dedicado a revisar el código de otros podría invertirse en desarrollar nuevas características o corregir errores. Además, señalan que los beneficios en calidad no son proporcionales al tiempo invertido.
2. Mandato vs. Opción: Otro punto de discusión es si los code reviews deben ser obligatorios. Los autores deberían escoger si quieren o no ser revisados.

Pero entonces ¿Cuál es la conclusión?

Como en muchos aspectos de la vida, la clave podría estar en encontrar un balance.

Quizás no se trata de descartar completamente los code reviews, sino de implementarlos de manera que maximicen su valor sin sacrificar la productividad.

Aquí te muestro cuáles son mis sugerencias.

1. Revisión Selectiva

Implementar una "revisión selectiva" significa establecer criterios claros que determinen cuándo es necesario un code review. Por ejemplo:

• Cambios críticos: Cualquier modificación en el código que afecte a la seguridad o a la arquitectura principal podría requerir revisión.
• Nuevas características: Los añadidos significativos o las modificaciones en las funcionalidades existentes pueden ser candidatos para revisión, mientras que cambios menores o correcciones de errores podrían no necesitarla.

Para facilitar este proceso, puedes utilizar herramientas como GitHub o GitLab, que permiten configurar reglas para que los pull requests requieran revisión solo si cumplen con ciertos criterios, como afectar a ciertos archivos o superar un cierto número de líneas de código modificadas.

2. Automatización

La automatización en los code reviews se puede lograr a través de herramientas de CI (Continuous Integration).

Estas herramientas ayudan a automatizar la revisión de código y otras pruebas de calidad antes de que los cambios se mezclen con el código principal. Algunas de estas herramientas pueden ser:

• Jenkins: Un servidor de automatización open source que permite automatizar las diferentes fases del desarrollo de software.
• Travis CI: Un servicio de CI que se integra con GitHub, corriendo automáticamente tus pruebas y despliegues.
• CircleCI: Ofrece CI y CD (Continuous Deployment) para desarrollar más rápido a través de la automatización.

Estas herramientas pueden configurarse para ejecutar suites de pruebas automáticamente, revisar el cumplimiento de las normas de código y hasta identificar problemas de seguridad.

Esto no solo ahorra tiempo sino que también asegura que los cambios cumplen con un nivel de calidad antes de ser revisados por humanos.

3. Cultura de Calidad

Fomentar una "cultura de calidad" implica crear un ambiente donde la calidad del código sea una responsabilidad compartida y donde los code reviews sean vistos como oportunidades de aprendizaje.

Algunas ideas para promover esto:

• Pair programming: Esta técnica, donde dos programadores trabajan juntos en una sola tarea, puede mejorar la calidad del código y reducir la necesidad de code reviews extensos.
• Sesiones de aprendizaje: Hacer sesiones regulares donde el equipo pueda compartir conocimientos, mejores prácticas y lecciones aprendidas de los code reviews puede ayudar a mejorar las habilidades de todos.
• Herramientas de feedback continuo: Herramientas como Reviewable, que facilitan la revisión de código y el feedback en línea, pueden promover un entorno de feedback constructivo y continuo.

Adoptar estas prácticas y herramientas puede hacer que los code reviews sean vistos como una parte integral y valorada del proceso de desarrollo de software.

Al final, se trata de equilibrar la eficiencia con la efectividad, asegurando que el código no solo se produzca rápidamente sino que también sea de alta calidad y fácil de mantener a largo plazo.

Para finalizar

Al final del día, los code reviews no son ni buenos ni malos per se. Su valor depende de cómo se implementen y de la actitud del equipo hacia ellos.

Te invito a reflexionar sobre estas ideas y considerar cómo los code reviews pueden adaptarse mejor a tu equipo de desarrollo.

¿Crees que puedan transformarse de un "impuesto a la productividad" en una "inversión en calidad"?

Nos vemos en la edición #26

Y recuerda, en el mundo del desarrollo de software, como en la vida, el equilibrio y la adaptación son las claves para el éxito.

Recuerda que si quieres hablar de algo en particular puedes sugerir el tema respondiendo este correo.

Hasta pronto 👊🏼