Code Review Process - C-Suite

Este documento descreve o processo formal de code review para o ecossistema C-Suite.

Visão Geral

O processo de code review garante qualidade de código, conhecimento compartilhado e detecção precoce de problemas.

Processo

1. Criar Pull Request

Criar branch a partir de main ou develop
Fazer alterações e commits
Criar Pull Request (PR) no GitHub/GitLab
Preencher template do PR com:
Descrição das mudanças
Motivação
Testes realizados
Checklist

2. Checklist de PR

Antes de solicitar review, verificar:

[ ] Código segue padrões do projeto (Black, isort)
[ ] Testes foram adicionados/atualizados
[ ] Documentação foi atualizada
[ ] Linting passa (make lint)
[ ] Testes passam (make test)
[ ] Não há secrets hardcoded
[ ] Logging apropriado foi adicionado
[ ] Tratamento de erros está implementado

3. Solicitar Review

Atribuir pelo menos 1 revisor
Adicionar labels apropriados (bugfix, feature, refactor, etc.)
Mencionar pessoas relevantes se necessário

4. Review

O revisor deve verificar:

Funcionalidade

[ ] Código faz o que se propõe?
[ ] Edge cases foram considerados?
[ ] Performance é adequada?

Qualidade de Código

[ ] Código é legível e bem estruturado?
[ ] Nomes de variáveis/funções são claros?
[ ] Comentários são necessários e úteis?
[ ] Não há código duplicado?

Segurança

[ ] Não há vulnerabilidades conhecidas?
[ ] Inputs são validados?
[ ] Secrets não estão hardcoded?
[ ] SQL injection protegido?

Testes

[ ] Testes cobrem casos principais?
[ ] Testes são claros e mantíveis?
[ ] Cobertura adequada?

Documentação

[ ] Docstrings estão presentes?
[ ] README atualizado se necessário?
[ ] Comentários explicam "por quê" não apenas "o quê"?

5. Aprovação

Pelo menos 1 aprovação é necessária
Para mudanças críticas, 2 aprovações podem ser necessárias
Aprovação pode ser condicional (aprovado após correções)

6. Merge

Após aprovação, autor pode fazer merge
Preferir "Squash and merge" para manter histórico limpo
Deletar branch após merge

Padrões de Código

Python

Seguir PEP 8
Usar Black para formatação
Usar isort para ordenação de imports
Type hints quando possível
Docstrings em todas as funções/classes públicas

Estrutura de Commits

tipo(escopo): descrição curta

Descrição mais detalhada se necessário

Fixes #123

Tipos:
- feat: Nova funcionalidade
- fix: Correção de bug
- docs: Documentação
- style: Formatação
- refactor: Refatoração
- test: Testes
- chore: Manutenção

Critérios de Aprovação

Aprovação Automática

Mudanças em documentação (docs/)
Correções de typos
Mudanças de formatação (após passar lint)

Aprovação Necessária

Mudanças em código de produção
Mudanças em APIs públicas
Mudanças em configurações de infraestrutura
Mudanças em schemas de banco de dados

Aprovação Dupla Necessária

Mudanças em autenticação/autorização
Mudanças em secrets management
Mudanças críticas de segurança
Mudanças que afetam múltiplos serviços

Comentários de Review

Tipos de Comentários

Must Fix: Bloqueia merge até correção
Should Fix: Recomendado, mas não bloqueia
Nice to Have: Sugestão de melhoria futura
Question: Pergunta para esclarecimento

Respondendo a Comentários

Responder a todos os comentários
Fazer correções ou explicar por que não
Marcar como resolvido quando aplicável

Ferramentas

GitHub

Usar GitHub Pull Requests
Configurar branch protection rules
Usar GitHub Actions para CI/CD

GitLab

Usar GitLab Merge Requests
Configurar merge request approvals
Usar GitLab CI/CD

Exemplo de Template de PR

## Descrição

Breve descrição das mudanças.

## Tipo de Mudança

- [ ] Bug fix
- [ ] Nova funcionalidade
- [ ] Breaking change
- [ ] Documentação

## Checklist

- [ ] Código segue padrões do projeto
- [ ] Testes foram adicionados/atualizados
- [ ] Documentação foi atualizada
- [ ] Linting passa
- [ ] Testes passam
- [ ] Não há secrets hardcoded

## Testes

Como testar estas mudanças?

## Screenshots (se aplicável)

## Referências

Issues relacionadas: #123

Best Practices

Reviews pequenos: PRs pequenos são mais fáceis de revisar
Reviews rápidos: Responder dentro de 24 horas
Feedback construtivo: Ser respeitoso e construtivo
Aprender: Usar reviews como oportunidade de aprendizado
Automatizar: Usar ferramentas para verificação automática