Preparação para o code review

Minha prática como profissional sênior é não entrar no feedback sem entender o objetivo da alteração. A preparação eficaz reduz retrabalho e aumenta a qualidade das decisões de design.

• Leia a descrição da PR com atenção, identifique o objetivo técnico e o impacto esperado no sistema.
• Reproduza o problema localmente quando possível e execute a suíte de testes relevante.
• Verifique o escopo da mudança (PR pequena > menos ruído). Se necessário, proponha dividir em etapas claras.
• Confirme que há testes cobrindo casos de borda, regressões e integração com dependências externas.
• Considere impactos em documentação, contratos de API e observabilidade (logs, métricas, tracing).

Fatores técnicos que merecem atenção

Além do funcionamento básico, o code review deve priorizar legibilidade, modularidade e contratos estáveis. Eis critérios práticos que guiono meus reviews:

• Legibilidade e nomes: funções devem ter nomes que expressem a responsabilidade. Comentários devem esclarecer o “porquê” quando o código não for óbvio.
• DRY e modularização: evite duplicação de lógica; promova composição de funções/módulos pequenos e coesos.
• Complexidade: alvos como funções com muitos caminhos lógicos devem ser refatorados para reduzir a complexidade ciclomática.
• Contratos de API: valide entradas, mantenha invariantes e documente os formatos esperados. Evite dependência de comportamentos implícitos.
• Tratamento de erros: padronize exceções/erros, inclua mensagens úteis e preserve a segurança do sistema diante de falhas.
• Desempenho e segurança: avalie gargalos óbvios, verifique consultas, processos assíncronos, validação de dados e potenciais vulnerabilidades.

Exemplo prático: evitar mutáveis por padrão em funções Python, um cenário comum de revisão. Veja o código abaixo:

# Mau: argumento mutável por padrão pode reter estado entre chamadas
def add_item(item, items=[]):
    items.append(item)
    return items

# Bom: evitar mutáveis por padrão usando None como sentinela
def add_item(item, items=None):
    if items is None:
        items = []
    items.append(item)
    return items

Comunicação e feedback

O valor de um code review está na clareza do feedback. Adote práticas que guiem a equipe de forma objetiva e construtiva:

• Feedback específico: aponte trechos relevantes (linhas, padrões) e explique o impacto técnico.
• Ofereça alternativas: sempre que possível, apresente uma refatoração ou solução viável.
• Evite ataques pessoais: foque no código, não no profissional.
• Contexto e decisão: registre o porquê da escolha (design docs, trade-offs e riscos).
• Exemplos ajudam: inclua snippets que ilustram o problema e a solução sugerida.

Processo de revisão e governança

Definições de processo ajudam a manter o ritmo sem sacrificar qualidade. Adoto estas práticas como padrão:

• Timebox: estabeleço um tempo máximo para a revisão (ex.: 60 minutos por PR) para manter o foco.
• Checklists: use um checklist explícito para evitar pular itens críticos (segurança, testes, documentação, performance).
• Definition of Done (DoD): critérios claros para considerar a PR pronta para merge.
• Automação onde faz sentido: lint estático, testes automatizados e validações de dependências para reduzir ruído humano.
• Priorização e triagem: classify as mudanças por blocking, critical, ou improvements, para alinhamento com o roadmap.