Optimizando la Colaboración: Prácticas para un Code Review efectivo.

9 min readNov 27, 2023

Hola! Me estoy mudando a https://elproyectobicicleta.substack.com/, sigue disfrutando de este Post y de más estrategias y experiencias para crecer dentro de la industria del software en mi newsletter.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

El Code Review es una práctica habitual dentro de la industria del software y dependiendo el tamaño de la compañía o del equipo puede tener algunas variaciones ;pero al final se buscan objetivos similares, principalmente mantener los estándares de calidad de nuestro software.

Aunque es verdad que algunos creemos que el Code review va más allá de solo cuidar “estándares” del código que se escribe en el día a día puesto que también:

Difunde el conocimiento dentro del equipo.
Es una forma de introducir a nuevos integrantes a un proyecto.
Fomenta el aprendizaje continuo, obteniendo feedback de nuestro trabajo.
Funciona para descubrir mejora continua dentro de nuestro código.
Asegura la calidad funcional (de negocio) del software desarrollado.
En ocasiones ayuda a encontrar errores, posibles problemas de rendimiento o vulnerabilidades.

La realidad es que todos son argumentos lo suficientemente válidos, y es lo que ha llevado a que más compañías confíen en el Code Review como parte de su flujo de trabajo ;pero el verdadero reto es lograr encontrar esas prácticas que ayuden a maximizar este proceso en los equipos, sin que esto se convierta en un paso extra o tedioso en el ciclo de desarrollo.

Code Reviews deficientes :(

Buscar errores

No enfoques esfuerzos en buscar bugs, no es el objetivo ni tampoco es el momento para buscar que hizo mal un compañero, somos personas y cometemos errores ;pero nadie se levanta con ganas de hacer las cosas mal (tal vez hay uno que otro bandido por ahí 😅), mientras tú señalas con 1 dedo, hay 3 dedos apuntando hacia ti . Sugiere escribir pruebas automáticas para dicha parte de software, aunque las pruebas si son parte de la revisión del código.

Verificar estándares de código

Dejemos de hacer comentarios sobre, validar máximo de longitud por línea de código, validar cantidad de líneas por clase, indentaciones, tamaño de argumento de una función entre otras, en su lugar haz uso de un analizador de código estático, linters o herramienta similar, que puedes configurar para verificar tu código de forma automática. Si ya la utilizas y aún sigues validando esto, es probable que necesites ajustar a reglas más estrictas.

Intentar cambiar toda una solución

Probablemente tengamos otros problemas dentro de nuestro proceso de desarrollo aunque es muy común cuando no hay tanta colaboración entre desarrolladores o equipos y no se generan discusiones técnicas previas, para este punto cambiar todo es complicado por todo el esfuerzo e impacto que implica, una forma de darle la vuelta es crear tareas, hablarlo con el equipo y pedir priorizarlas en siguientes iteraciones, sumado a generar foros discusión técnicos, tomar más iniciativa, más propuestas sobre quejas, dale una mano a quien la necesite, el código se escribe individual ;pero se desarrolla en equipo.

Pull Requests abiertas por extensos periodos de tiempo

El Code review debería ser de las primeras tareas de un desarrollador al iniciar su día, cada periodo de tiempo que pasa sin que una pull request sea revisada, probablemente está teniendo un impacto negativo en el trabajo de otro desarrollador, de un equipo, de una área e incluso de la compañía. Nuestro trabajo es escribir software y agregar valor a usuarios de manera efectiva, con calidad y continua, diseña un flujo de trabajo dentro la herramienta que utilices de versionado de código que permita distribuir la carga del Code review entre los diferentes miembros del equipo, se proactivo y asigna tiempos durante tu jornada laboral para realizar esta actividad, definir una plantilla de como redactar un pull request, y establecer acuerdos de colaboración también ayuda a simplificar el proceso.

No hacerlo constructivo

Considero que es el más dañino para los equipos, entendamos que no es una competencia de quien sabe más, no es una carrera para saber quien tiene la razón, no se trata de presionar “Approve” solo por hacerlo rápido e intentar no bloquear a nadie o quedar bien con alguien, deja el ego a un lado, no se trata de generar discusiones para problemas simples o que aún no existen, nadie debe saltarse el proceso ni aunque sea “manager”, nadie es tan senior como para no pasar por una revisión, no se trata de omitir las pull requests de X persona para evitar el conflicto, no lo hagas personal, todos tenemos un mal día, hay que tener esa empatía cuando es necesaria y la humildad para reconocer que somos humanos y seguiremos equivocandonos, aprendamos de esos errores y hacia adelante. Dedica la atención que merece el trabajo de tus compañeros, dejemos de mirarlo como una tarea extra, no lo es, es parte de nuestras responsabilidades, eso significa respetar al equipo, los acuerdos, el proyecto y ser profesional.

¿Qué mirar en el Code review?

Reglas de funcionalidad

La solución propuesta, la solución hace lo que dice que debe hacer, y resuelve la problemática descrita, es decir que las reglas de negocio están correctamente implementadas. Si los requerimientos no se cumplen, ningún comentario tiene sentido, es la razón de existir de una pull request o de una tarea, debe resolver un problema específico (Extraño no? ;pero he visto casos donde se resuelve cualquier cosa, que realmente no es la tarea objetivo).
Cuando la tarea es de capa de presentación UI, ya sea móvil o web es importante validar que la implementación cumple con el diseño de UI.
Si implica cambiar o actualizar APIs, validar que sigue siendo compatible con todos los clientes y no genera “break changes”.
Si hay cambios en bases de datos o tablas, asegurar que contiene migraciones y no va generar daños colaterales.
Dentro de los equipos existen estrategias específicas de creación de software, a las cuales se les debe poner atención, como herramientas de análisis para medir alguna nueva funcionalidad o experimentos, implementación de feature toggles, o similar.

Calidad de código

Asegurar que el código es consistente con el diseño, patrones y arquitectura definida.
¿La solución es lo mínimamente viable para el problema?, evita caer en la sobre ingeniería o complicar las soluciones de más ;pero no perder de vista siempre escribir código y soluciones de calidad.
Validar que se añadieron pruebas automáticas y están bien escritas, buscamos pruebas automáticas rápidas y confiables.
El “naming” para algunos es tedioso ;pero mantener código es trabajo de personas y mientras sea más claro, será más simple de entender cualquier parte del código.
Dependiendo la plataforma ya sea, Android, iOS, Mobile (Flutter, React Native, etc), Web (algún framework JS), o Backend (en cualquier lenguaje o framework) pueden existir temas muy puntuales a tener en cuenta, aunque es bueno definirlo y considerarlo como parte de los estándares del proyecto de código.

Es muy complicado definir el 100% de los puntos en los que deberíamos enfocar los esfuerzos durante la revisión de código ;pero estos son algunos de los que me han funcionado, sugiero que ajustes de acuerdo a la necesidad del proyecto y el tamaño de tu equipo.

Principios del Code Review pragmático

Los participantes en una revisión de código son el ”Author”, que escribe el código y lo envía para su revisión, y el “Reviewer” (1 o N según el flujo definido), quien lee el código y decide cuándo está listo para fusionarse en el código base del equipo, al final esto termina en un flujo de comunicación entre personas, que no hacerlo de la mejor manera posible puede generar una mala colaboración entre los miembros.

Code Review para el “Author”

Auto-code review antes de pedirle a alguien más que lo haga, hazlo como si fueras un revisor externo de tu propio trabajo, es la mejor manera de optimizar el tiempo del equipo.
Redacta y específica detalladamente el Pull Request, sé claro con los requerimientos y explica un poco el cómo lo hiciste, apóyate de un pull request template de ser necesario, piensa que la redacción es para tu equipo, no para ti, el equipo debe entender que estás intentando solucionar para que la revisión aporte valor.
Crea una Pull request, por tarea, estas deben resolver solo un problema a la vez, genera la múltiple cantidad de pull request que sean necesarias mientras tengan un objetivo claro, mezclar nuevas funcionalidades, refactors, reparación de errores o mejoras de performance siempre es una mala idea, probablemente va a complicar el trabajo de revisión, la fusión de código (merge conflicts) e incluso un rollback sumado que hará que el tiempo en revisión y finalización de una tarea demore días.
Enriquece tu Pull request con links de referencia a temas que te ayudaron a resolver el problema, screenshots, documentación y todo lo que ayude a la persona que va revisar a entender todo y a hacerlo simple.
Indica cómo se puede probar tu trabajo, idealmente es que sea de forma automática ;pero si no explica por qué y las pruebas que tendrá que realizar el revisor para comprobar que funciona como se espera. Agrega toda la evidencia posible que ayude a hacer visible que es funcional.
Todos los comentarios acéptalos, cuestiona lo que no entiendas, pide una llamada o clarificación de algún punto que sea complejo ;pero no te quedes con la duda, ni mucho menos asumas nada. Siempre da una reacción a los comentarios, nunca dejes uno solo sin responder, eso hace que el revisor esté tranquilo de que si leiste y atendiste las sugerencias.

Code Review para el “Reviewer”

Paciencia y Respeto, no todos en el equipo tienen el mismo conocimiento, algunos tienen más tiempo en el proyecto o otros menos, piensa que nadie hace mal su trabajo a propósito. Si algo no se ve bien, trate de descubrir por qué casi siempre hay una razón.
Entiende el contexto completo del problema que está resolviendo el Pull request, eso implica entender ciertas reglas de negocio, no solo de código, si no las comprendes pregunta no te quedes con la duda, también es bueno levantar la mano y reconocer que no dominas ese scope, “Esto no lo conozco mucho, hice comentarios sobre el código ;pero prefiero que alguien más ayude a revisar las reglas de negocio”, la revisión debe tener valor, no se trata de dar aprobaciones en base a especulación.
No olvidar que se trata de la calidad del código, no de tener razón. Comentarios o sugerencias pueden rechazarse si existen motivos de valor para ello, no te lo tomes personal es por el bien del proyecto.
Se claro con tus comentarios, siempre intenta explicar el por que en los que no son tan obvios de entender, incluso si lo son es mejor aclarar para no asumir.
Se humilde y empático con tus comentarios, haz sugerencias, no exigencias, redacta como equipo, cambia los “tienes ” por él “tenemos” somos un conjunto y buscamos el mismo objetivo. Haz preguntas que inviten a pensar en el problema, mira este ejemplo:

“¿Qué te parecería renombrar la variable “payM” por algo más acorde con el negocio?”

“Si cambiamos la variable “payM” por “payment” podría ser más claro, ¿Qué piensas?”

“No se entiende “payM”, esta mal”

“Mal nombre, cambialo”

La manera de pedir es la manera en que lo vas a recibir.

Evita el conflicto ;pero no el problema, si la conversación se está complicando, evita los threads con comentarios largos, todas son perspectivas válidas ;pero es mejor hacer una “Video call” e ir a los puntos específicos, esto puede ahorrarte tiempo y disgustos, se comparte pantalla y se resuelven como equipo.
No seas un policía que dice todo lo que está mal, fomenta la colaboración orgánica, cuestiona en lugar de mandar. Si no sigue los estándares que se piden, realiza una llamada con la persona y explica por qué está mal, no lo trates mal por que no lo hizo como tu querías, o no siguió los acuerdos, tal vez recibió un mal onboarding, simplemente no lo sabía, o se le fue ;pero hay que entender el por que y la razón, para poder mejorarlo en la siguiente. Esto pasa mucho con nuevos integrantes de un equipo.

Conclusión

Cada equipo es distinto y tienen necesidades muy específicas, experimenta e implementa para tu caso, revisa con frecuencia que se puede mejorar y lo que no funciona cambialo, este proceso es para simplificar la vida de todos, utilizalo a tu favor para generar un buen software de calidad, para aprender a recibir feedback, para aprender de desarrolladores más experimentados o para ayudar a alguien más, no hay mejor manera de crecer que crecer junto con personas que buscan un camino similar al tuyo. El software es una tarea de equipo.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” Martin Fowler