Por qué tus code reviews generan conflictos (y cómo solucionarlo)

Hace dos semanas, un dev senior de mi equipo dejó un comentario en un PR: "Este código es horrible. Rehacelo."

El pull request se cerró sin merge. El dev junior no volvió a hacer commits por tres días. El ambiente se puso tenso.

Eso pasa cuando confundimos hacer code review con ser un crítico despiadado. La diferencia entre un review que suma y uno que resta está en los detalles.

El problema no es el qué, es el cómo

Todos sabemos que los code reviews son necesarios. Reducen bugs, mejoran la calidad del código y hacen que el conocimiento circule por el equipo.

Pero acá está la cosa: la mayoría de los reviews se enfocan solo en el código y se olvidan de la persona que lo escribió.

Cuando dejás un comentario como "Esto está mal", técnicamente podés tener razón. Pero socialmente acabás de crear un problema más grande que el bug que querías prevenir.

Las 4 reglas del feedback constructivo

1. Criticá el código, no al programador

❌ Mal: "No sabés usar async/await correctamente" ✅ Bien: "Este bloque podría beneficiarse de async/await para manejar mejor la asincronía"

La diferencia es sutil pero poderosa. En el primer caso, estás atacando la competencia de la persona. En el segundo, estás señalando una oportunidad de mejora en el código.

2. Explicá el por qué, no solo el qué

❌ Mal: "Usá const en lugar de let" ✅ Bien: "Usá const acá porque el valor no cambia. Ayuda a prevenir reasignaciones accidentales y hace más claro que es inmutable"

Cuando explicás el razonamiento, no solo corregís el código actual, sino que educás para el futuro.

3. Ofrecé alternativas, no órdenes

❌ Mal: "Cambiá esto por un map" ✅ Bien: "¿Qué te parece usar map acá? Queda más funcional y es más fácil de testear"

Las preguntas abren conversación. Las órdenes la cierran.

4. Reconocé lo que está bien

❌ Mal: Solo señalar errores ✅ Bien: "Me gusta cómo manejaste el error handling acá. Muy prolijo. Una cosa menor: podrías extraer esta validación a una función separada"

Un comentario positivo al principio cambia completamente el tono del review.

Técnicas específicas que funcionan

La técnica del sándwich mejorado

El clásico "sándwich" (positivo-negativo-positivo) puede sonar falso. Mejor usá esta versión:

1. Empezá con algo específico que esté bien hecho
2. Dá el feedback de mejora con contexto
3. Terminá con una pregunta o invitación al diálogo

Ejemplo:

"El manejo de errores en handleSubmit está muy bien pensado, 
especialmente cómo diferenciás entre errores de validación y de red.

Una cosa que podría mejorarse: esta función está haciendo demasiadas 
cosas (validar, hacer el request, actualizar el state). 
¿Te parece si la dividimos en funciones más pequeñas?

Te dejo un ejemplo de cómo podría quedar si te sirve."

La regla de los ejemplos

Siempre que sea posible, incluí un ejemplo de código. No hace falta que sea perfecto, pero ayuda a que el otro entienda qué tenés en mente.

// En lugar de solo decir "extraé esto a una función"
// Mostrá cómo:

const validateUser = (user) => {
  if (!user.email || !user.password) {
    throw new Error('Email y password son requeridos');
  }
  // resto de validaciones
};

Los modificadores que suavizan

Esas palabritas que cambian todo el tono:

• "Quizás podrías..."
• "¿Qué te parece si...?"
• "Una alternativa podría ser..."
• "Me pregunto si..."

Suenan menores, pero hacen que el feedback se sienta como una sugerencia colaborativa en lugar de una crítica.

Cómo manejar diferentes situaciones

Cuando el código tiene problemas serios

Si el código tiene issues importantes, no endulces tanto que pierdas el mensaje. Pero seguí siendo específico:

"Este approach va a generar problemas de performance 
cuando tengamos más de 100 items. El problema está en 
que estamos haciendo un fetch por cada item en el loop.

¿Te parece si cambiamos a un batch request? Te paso 
un ejemplo de cómo podríamos implementarlo."

Cuando es una preferencia estilística

Acá sé honesto sobre que es tu preferencia:

"Esto funciona perfecto. Una preferencia personal: 
me gusta más usar object destructuring acá porque 
queda más limpio, pero tu approach está bien también."

Cuando el dev es muy junior

Dale más contexto y educación:

"Muy buen primer PR! Una cosa que vas a ver seguido 
en React: cuando tenés un efecto que depende de una 
variable, la tenés que poner en el array de dependencias. 
Sino puede generar bugs raros.

Te dejo un link que explica bien por qué pasa esto."

Las herramientas también importan

Elegí bien dónde hacés cada tipo de comentario:

• Issues grandes: Hablalo en persona o videollamada
• Cambios menores: Comentarios en línea
• Conceptos generales: Un comentario general en el PR
• Emergencias: Slack primero, después review

Checklist para tu próximo review

Antes de enviar tus comentarios, preguntate:

• ¿Critiqué el código o a la persona?
• ¿Expliqué por qué sugiero el cambio?
• ¿Incluí algo positivo específico?
• ¿Usé un tono colaborativo?
• ¿Di ejemplos cuando era necesario?
• ¿Es algo que realmente importa o es solo mi preferencia?

Preguntas frecuentes

¿Qué hago si el dev se ofende igual? Hablalo en privado. A veces hay contexto que no sabés (mal día, presión, etc.). La empatía siempre suma.

¿Cuántos comentarios son demasiados? Si tenés más de 10-15 comentarios en un PR, mejor hablalo en vivo. Muchos comentarios escritos se sienten como un ataque.

¿Debo aprobar PRs con issues menores? Sí, si no afectan funcionalidad. Podés aprobar con comentarios "nit" (minor) que el dev puede aplicar después.

Los code reviews no son solo sobre código. Son sobre construir equipos que funcionen bien juntos. Cuando das feedback de una forma que respeta a la persona del otro lado, no solo mejorás el código – mejorás la cultura de todo el equipo.