4 min read
Todos hemos recibido ese comentario en un code review (revisión de código): “Esto está mal, ¿por qué lo hiciste así?”. Siete palabras que no enseñan nada, no proponen nada, y dejan a la otra persona a la defensiva por el resto del día.
Y también, seamos honestos, todos hemos escrito un comentario parecido alguna vez. Con prisa, entre reuniones, sin mala intención. El problema es que en un code review las palabras escritas no tienen tono de voz ni lenguaje corporal. Lo que en persona sonaría neutral, por escrito suena a ataque.
La buena noticia: dar retroalimentación técnica sin destruir la motivación es una habilidad que se entrena. Aquí van las técnicas que mejor me han funcionado.
1. Comentá el código, no la persona
Hay una diferencia enorme entre estas dos frases:
- “Hiciste esta consulta muy ineficiente.”
- “Esta consulta hace un full scan de la tabla. ¿Qué te parece si agregamos un índice sobre
customer_id?”
La primera apunta a la persona (“hiciste”). La segunda apunta al código y además propone una salida. Mismo problema técnico, dos efectos completamente distintos en quien lo recibe.
2. Preguntá antes de asumir
Muchas veces lo que parece un error es una decisión con contexto que no tenemos. En lugar de “esto está mal”, probá con “¿qué te llevó a este enfoque?”. Dos cosas pueden pasar: descubrís un contexto que no conocías, o la persona se da cuenta sola del problema al explicarlo. Ambos resultados son mejores que una corrección impuesta.
3. Distinguí entre “bloqueante” y “opinión”
No todos los comentarios pesan igual. Un bug que va a tirar producción no es lo mismo que tu preferencia personal por los nombres de variables. Hacé la diferencia explícita:
- [Bloqueante]: “Este método no libera la conexión si hay una excepción — necesitamos un try-with-resources antes de aprobar.”
- [Sugerencia]: “Yo usaría
customerOrdersen lugar delist2, pero no es bloqueante.” - [Nit] (detalle menor): “Espacio extra en la línea 42.”
Cuando todo parece igual de grave, la persona no sabe qué priorizar y siente que nada de lo que hizo sirve. Cuando las categorías son claras, el review se convierte en una conversación productiva.
4. Reconocé lo bueno (en serio, hacelo)
Los code reviews no son solo para encontrar errores. Si alguien resolvió algo de forma elegante, decilo: “No conocía este método de la API de Streams, buena solución”. Ese comentario cuesta diez segundos y logra dos cosas: refuerza las buenas prácticas y hace que los comentarios críticos se reciban como parte de un balance, no como una lluvia de golpes.
5. Si el hilo pasa de tres respuestas, hablen
Un hilo de code review con ocho respuestas cruzadas es una señal de que el texto ya no alcanza. Levantate, agendá 15 minutos, o mandá un mensaje: “¿Lo vemos en una llamada rápida?”. Cinco minutos de conversación resuelven lo que veinte comentarios escritos solo empeoran. Después, documentá la conclusión en el PR (Pull Request — solicitud de integración de cambios) para que quede el registro.
6. Cuidá el review de personas junior
Para alguien con poca experiencia, su primer code review puede definir su relación con el equipo. Un review brutal enseña a esconder el código y a tener miedo de preguntar. Un review exigente pero respetuoso enseña que equivocarse es parte del proceso. Sé más pedagógico con quien está empezando: explicá el porqué detrás de cada comentario, no solo el qué.
El checklist antes de enviar tus comentarios
- ¿Mi comentario apunta al código o a la persona?
- ¿Propuse una alternativa o solo señalé el problema?
- ¿Está claro qué es bloqueante y qué es opinión?
- ¿Reconocí al menos una cosa bien hecha?
- ¿Este hilo ya necesita una conversación en vivo?
Treinta segundos de revisión antes de enviar. Ese es todo el costo de un code review que construye en lugar de destruir.
Conclusión
El objetivo de un code review nunca fue demostrar quién sabe más. Es mejorar el código y, al mismo tiempo, mejorar al equipo. Un equipo donde la gente tiene miedo de abrir un PR es un equipo que va a esconder los problemas hasta que exploten en producción.
La próxima vez que estés por escribir “esto está mal”, respirá y reformulá. Tu yo del futuro — el que necesita que ese compañero le revise el código a vos — te lo va a agradecer.
Recordá suscribirte aquí para recibir los próximos posts directamente en tu correo.
Referencias:
Cómo ganar amigos e influir sobre las personas — Dale Carnegie
The Culture Code — Daniel Coyle