Code Reviews: Cómo Dar Feedback Sin Destruir a Nadie
⏱ Tiempo de lectura: 7 minutos
¿Alguna vez abriste un PR y, después de leer los comentarios, sentiste que te habían reescrito el alma? Sí, ese momento en que alguien escribe "esto está mal" sin más contexto, y tú te quedas mirando la pantalla pensando si dedicarte a otra cosa. O peor: eres tú el revisor, dejas diez comentarios técnicamente correctos, y la persona del otro lado desaparece en silencio durante tres días.
Los code reviews son una de las herramientas más poderosas que tiene un equipo de desarrollo. Mejoran la calidad del código, distribuyen conocimiento y detectan bugs antes de que lleguen a producción. Pero también pueden convertirse en el lugar donde la moral del equipo va a morir lentamente, si nadie se toma el tiempo de pensar cómo se está comunicando.
Llevo más de una década haciendo y recibiendo reviews. He visto equipos donde nadie quería abrir un PR por miedo a los comentarios, y equipos donde los reviews eran casi una conversación de café. La diferencia no era técnica. Era humana.
El problema no es el código, es el tono
Cuando revisas código ajeno, hay una trampa muy común: enfocarte tanto en lo que está "mal" que te olvidas de que hay una persona detrás de esas líneas. Alguien que invirtió tiempo, tomó decisiones, y probablemente también tuvo dudas.
Un comentario como "este enfoque es ineficiente" puede ser técnicamente válido. Pero sin contexto, sin alternativa, y sin ninguna señal de que entiendes por qué la persona lo hizo así, suena a ataque. Y cuando alguien siente que lo atacan, deja de escuchar. Empieza a defenderse.
Algo que me ha funcionado es cambiar la forma en que formulo los comentarios. En vez de "esto está mal", intento algo como "¿consideraste usar X aquí? Creo que podría simplificar el flujo bastante". Mismo mensaje técnico. Completamente diferente en recepción.
La diferencia entre un comentario y una conversación
Un comentario de code review no debería sentirse como un veredicto. Debería sentirse como el inicio de una conversación. Ojo que esto no significa que todo deba ser un debate filosófico — a veces un typo es un typo y listo. Pero cuando hay decisiones de diseño o arquitectura en juego, el "¿qué pensabas aquí?" vale más que cualquier explicación unilateral.
El punto es que la persona que escribió el código tiene contexto que tú no tienes. Quizás ese "hack raro" existe porque hay un bug en una librería externa. Quizás esa función larga es temporal y hay un ticket abierto para refactorizarla. Preguntar antes de concluir no es debilidad — es inteligencia.
Dar feedback que realmente enseña
Hay una diferencia enorme entre un review que corrige y uno que enseña. El primero resuelve el PR. El segundo hace crecer al equipo.
Cuando dejas un comentario explicando por qué algo podría hacerse diferente, no solo estás ayudando con ese PR — estás construyendo criterio en la otra persona para que la próxima vez lo piense sola. Eso escala. Un equipo donde todos entienden el razonamiento detrás de las decisiones toma mejores decisiones en conjunto.
Algo concreto: cuando señalo un problema de performance o de legibilidad, intento siempre incluir una referencia, un ejemplo, o al menos una explicación de dos líneas. No porque sea obligatorio, sino porque si yo ya hice el trabajo mental de entender el problema, compartirlo cuesta poco y vale mucho.
Los comentarios positivos también cuentan
Esto es algo que se ignora brutalmente en la mayoría de los equipos. Si alguien resolvió algo de forma elegante, dilo. Un "nice approach here" o "esto está muy limpio, lo voy a robar" no es perder el tiempo. Es recordarle a la otra persona que el trabajo bien hecho se nota.
Los reviews donde solo aparecen problemas crean una asociación inconsciente: abrir un PR = recibir críticas. Con el tiempo, la gente empieza a evitar mandar cosas a review, o manda menos, o manda más tarde. El resultado es código que llega a producción con menos ojos encima. Exactamente lo contrario de lo que queremos.
Recibir feedback sin ponerte a la defensiva
Ahora bien, esto va en dos direcciones. Saber recibir un code review también es una habilidad, y no viene gratis.
La trampa más común al recibir feedback es tomarlo como algo personal. Tu código no eres tú. Esa función que escribiste a las 11 de la noche con tres cafés encima no define tu valor como desarrollador. Es solo código. Y el código siempre puede mejorar.
Dicho esto, también tienes derecho a no estar de acuerdo. Si alguien sugiere un cambio que crees que no tiene sentido, explícalo. Con argumentos técnicos, sin drama. Los mejores reviews que he tenido terminaron con el revisor cambiando de opinión después de escuchar el contexto. Eso no es ganar una discusión — es llegar a una solución mejor entre dos.
Cómo separar el ego del código
Una cosa que me ayudó mucho fue pensar en el código como algo que le pertenece al equipo, no a mí. Una vez que hago un merge, ese código es de todos. Y si es de todos, tiene sentido que todos opinen sobre él.
Eso cambia la perspectiva. Ya no es "están atacando mi código". Es "están ayudando a mejorar algo que vamos a mantener juntos". No siempre es fácil llegar a ese mindset, especialmente cuando llevas días en una feature complicada. Pero vale la pena intentarlo.
Establecer normas de review en el equipo
Si tienes influencia sobre cómo trabaja tu equipo, considera proponer una guía de code reviews. No un documento de 40 páginas — algo simple, acordado entre todos, que deje claro qué se espera de un buen review.
Algunas cosas que funcionan bien en equipos que conozco: distinguir entre comentarios bloqueantes y sugerencias opcionales (por ejemplo, prefijando con nit: los que son menores), definir un tiempo máximo para responder un review abierto, y acordar que ningún comentario se cierra sin respuesta, aunque sea un simple "de acuerdo, lo cambio".
No es burocracia. Es claridad. Y la claridad reduce fricción.
Antes de irte
Si has estado en un equipo donde los reviews se sienten como un campo minado, sé exactamente cómo se siente eso. Es agotador, y muchas veces no es culpa de nadie en particular — simplemente nadie se tomó el tiempo de hablar sobre cómo hacerlos bien.
No tienes que cambiar todo de golpe ni convencer a todo tu equipo de una vez. Empieza por tu próximo comentario.
Escribe el siguiente review como si quisieras que esa persona aprendiera algo, no como si quisieras demostrar que tú ya lo sabías. Eso solo ya cambia bastante las cosas.
💬 Comentarios