Un code review puede ser la mejor herramienta de aprendizaje de un equipo o la fuente número uno de fricción. La diferencia casi nunca está en el código: está en el tono y en el foco.

Si revisas

  • Critica el código, no a la persona. “Esta función hace dos cosas” en vez de “no sabes separar responsabilidades”.
  • Distingue lo bloqueante de lo opcional. Marca lo que es preferencia con un prefijo tipo nit: para que no parezca obligatorio.
  • Pregunta antes de afirmar. “¿Hay una razón para no usar map aquí?” abre conversación; “usa map” la cierra.
  • Reconoce lo bueno. Un “buena solución para el caso borde” cuesta cero y motiva.

Si te revisan

  • Despersonaliza. No es tu código el que se revisa, es el código. Nadie te está atacando.
  • Responde a todo, aunque sea con un 👍 o explicando por qué no aplicas un cambio.
  • PRs pequeños. Un diff de 1000 líneas no recibe un review, recibe un “LGTM” de rendición.

El objetivo real

No es encontrar fallos: es que el código entre a main mejor de lo que salió y que ambas personas aprendan algo. Si tu review no enseña nada ni mejora nada, sobra.