Ofício, qualidade e times · Iniciante

Revisão de código que melhora em vez de atrasar

Em uma linha: Uma boa revisão é pequena, rápida e focada em correção e manutenibilidade — não nas preferências de estilo que uma ferramenta automática deveria aplicar.

Tamanho

Uma pull request de duzentas linhas recebe comentários reais; uma de duas mil recebe 'parece bom'. Divida. Se não der para dividir, escreva na descrição um caminho de leitura recomendado.

Sobre o que comentar

Correção, casos limites, segurança, performance nos pontos sensíveis e clareza para quem vai ler daqui a um ano. Estilo, espaços e ordem de imports — para uma ferramenta automática, não para uma pessoa.

Formule comentários como uma pergunta ou sugestão, e marque o que bloqueia e o que é só uma opinião. 'Bloqueante: isso permite acesso ao recurso de outro usuário' é mais claro do que uma dica educada.

Tempo de resposta

Uma revisão que espera dois dias para usuários e produz branches longos. Defina uma norma — por exemplo, responder em meio dia — e trate-a como qualquer compromisso do time.

Indo mais fundo

Adicione à lista de verificação da revisão itens difíceis de aplicar automaticamente: um teste foi adicionado, a mudança é compatível retroativamente, a documentação foi atualizada e o que acontece em caso de falha. Essas quatro perguntas capturam a maior parte do que é esquecido.