Skip to main content

Code Review

Camada: Arquitetura — Padrões e boas práticas técnicas para o time de desenvolvimento. Aplica-se a: Todo o processo de revisão de código do CRM.

1. Práticas da Equipe​

  • Documente e padronize o processo de revisão de código — todos devem conhecê-lo.
  • Garanta que a Definição de Pronto (DoD) esteja documentada e clara para todos.
  • Defina um processo formal de resolução de conflitos em revisões.
  • Mantenha um guia de estilo definitivo — ele é a autoridade absoluta em questões de estilo.
  • Use automação para acelerar revisões: linting, formatação, análise estática.
  • Defina SLAs claros para prazos de revisão — uma PR não deve ficar bloqueada.
  • Use as revisões como oportunidade de compartilhamento de conhecimento.
  • Incentive revisões em áreas desconhecidas para ampliar o conhecimento do time.
  • Reconheça e valorize feedback de qualidade consistente.
  • Realize sessões periódicas para discutir padrões e tendências identificadas nas revisões.

2. Antes de Abrir o PR (Autor)​

  • Siga os padrões de codificação e diretrizes da equipe.
  • Mantenha consistência com o design e a arquitetura existente do projeto.
  • Divida tarefas complexas em PRs menores e fáceis de revisar.
  • Escreva testes automatizados para a mudança — se é um bugfix, escreva um teste que falhe sem a correção.
  • Escreva ou atualize a documentação afetada.
  • Considere o impacto da mudança em outras partes do sistema.
  • Anote dúvidas e pontos de atenção para discutir durante a revisão.

3. Ao Submeter o PR (Autor)​

  • Revise seu próprio código antes de abrir a PR.
  • Verifique se as mudanças foram testadas em ambiente de desenvolvimento.
  • Confirme que o código segue os padrões de codificação.
  • Identifique previamente riscos de performance, segurança ou escalabilidade e documente-os na PR.
  • Preencha adequadamente: título, descrição, screenshots, links relevantes e alterações de configuração.
  • Aborde o processo com mente aberta para colaboração.

4. Antes de Revisar (Revisor)​

  • Compreenda os requisitos e o contexto da mudança.
  • Prepare uma lista de itens que deveriam ser cobertos pelas alterações.
  • Certifique-se de entender a base de código e a arquitetura afetada.
  • Revise documentações e especificações de design relacionadas.
  • Identifique riscos potenciais antes de iniciar a revisão.
  • Determine o nível de revisão adequado com base no escopo e impacto.

5. Durante a Revisão (Revisor)​

  • Seja respeitoso e profissional — sem ataques pessoais ou comentários depreciativos.
  • Forneça feedback claro e acionável com sugestões específicas de melhoria.
  • Priorize o feedback — comece pelos problemas mais críticos.
  • O guia de estilo da equipe é a autoridade absoluta em estilo — não substitua por preferências pessoais.
  • Prefixe comentários não-críticos com "Nit:" para deixar claro que não são bloqueantes.
  • Revise todos os testes para verificar cobertura adequada da funcionalidade.
  • Confirme que a documentação relevante foi atualizada.
  • Identifique preocupações de performance, segurança e escalabilidade.
  • Busque melhoria contínua, não perfeição.
  • Forneça também feedback positivo — reforce boas práticas.
  • Considere programação em pares como alternativa para trechos complexos.

6. Após o Feedback (Autor)​

  • Enderece todos os feedbacks recebidos.
  • Implemente as mudanças sugeridas e explique decisões quando necessário.
  • Execute os testes e certifique-se de que todos passam após as alterações.
  • Atualize documentação e comentários de código afetados.
  • Busque feedback de outros membros se houver dúvida sobre as mudanças.
  • Submeta para segunda revisão se as mudanças foram significativas.

7. Segunda Revisão (Revisor)​

  • Resolva opiniões conflitantes em tempo hábil — não deixe PR parada por discordância.
  • Verifique se todos os feedbacks foram endereçados.
  • Execute os testes novamente e confirme que passam.
  • Esteja aberto ao feedback do autor sobre suas sugestões.

8. Após a Aprovação (Ambos)​

  • Faça o merge na branch principal/de feature.
  • Verifique se a mudança está funcionando conforme esperado em produção.
  • Monitore performance e funcionalidade após o deploy.
  • Resolva prontamente qualquer problema que surgir.