Um code review pode ser a melhor ferramenta de aprendizado de um time ou a sua fonte número um de atrito. A diferença quase nunca está no código: está no tom e no foco.

Se você revisa

  • Critique o código, não a pessoa. “Esta função faz duas coisas” em vez de “você não sabe separar responsabilidades”.
  • Separe o bloqueante do opcional. Marque preferências com um prefixo tipo nit: para que não pareçam obrigatórias.
  • Pergunte antes de afirmar. “Há um motivo para não usar map aqui?” abre conversa; “use map” a fecha.
  • Reconheça o que está bom. Um “boa solução para o caso de borda” custa zero e motiva.

Se revisam você

  • Despersonalize. Não é o seu código que está sendo revisado, é o código. Ninguém está te atacando.
  • Responda a tudo, mesmo que seja com um 👍 ou explicando por que não vai aplicar uma mudança.
  • PRs pequenos. Um diff de 1000 linhas não recebe um review, recebe um “LGTM” de rendição.

O objetivo real

Não é encontrar falhas: é que o código entre na main melhor do que saiu, e que as duas pessoas aprendam algo. Se o seu review não ensina nada nem melhora nada, é ruído.