Diretrizes de Revisão de Código
Revisões de PRs de Rust equilibram correção, design de API e operabilidade. Os revisores priorizam panics, unsafe, bloqueio assíncrono, mapeamento de erros e alterações de dependência.
Receita
Os revisores analisam nesta ordem:
- Descrição do PR vincula o ticket e explica o porquê
- CI verde (fmt, clippy, test, build travado)
- Tamanho do diff razoável para o tópico
- Testes cobrem a alteração de comportamento
- Caminhos sensíveis à segurança (autenticação, SQL, FFI)
Quando usar isto:
- Todo PR antes da aprovação
- Treinamento de novos revisores
- Calibragem de detalhes vs. bloqueadores
Exemplo de Trabalho
Bloqueadores (solicitar alterações)
// Bloqueando DB em handler assíncrono
async fn handler() {
std::thread::sleep(Duration::from_secs(1)); // BLOQUEADOR
}
// unwrap em código de biblioteca
pub fn parse(s: &str) -> User {
serde_json::from_str(s).unwrap() // BLOQUEADOR no crate de domínio
}
// unsafe sem comentário SAFETY
unsafe { ptr.read() } // BLOQUEADORImportante (deve corrigir)
- Nova dependência sem
cargo deny/ aprovação da equipe Cargo.lockausente no bump de dependência de crate binário- Falta
#[instrument]no novo limite de serviço assíncrono - Clone em struct grande em loop sem justificativa
Detalhe (opcional)
- Discussão de nomes quando rustfmt/clippy limpos
- Micro-otimizações sem dados de perfil
Mergulho Profundo
Checklist de Revisão
| Área | Procurar |
|---|---|
| Erros | Erros tipados, sem vazamento de internos em HTTP |
| Async | spawn_blocking para IO síncrono/CPU |
| SQL | Consultas parametrizadas, migração incluída |
| API | Alterações que quebram anotadas, bump de semver |
| Testes | Unitário + integração para caminhos de falha |
| Docs | Itens públicos documentados |
| Observabilidade | tracing em novos endpoints |
Tom
Faça perguntas ("Isso pode travar após await?") em vez de acusações. Link para seções do cookbook.
Armadilhas
- Aprovação cega de CI verde - bugs lógicos ainda escapam. Correção: ler as asserções de teste.
- Revisão apenas de estilo - perde a correção. Correção: seguir a ordem de prioridade acima.
- Bloquear por preferência - fadiga da equipe. Correção: codificar em clippy/rustfmt.
- Ignorar tamanho do PR - drive-by de 2000 linhas. Correção: solicitar divisão.
- Ignorar lente de segurança em diffs pequenos - bypass de autenticação em uma linha. Correção: sempre verificar caminhos de autenticação.
Alternativas
| Alternativa | Usar Quando | Não Usar Quando |
|---|---|---|
| Revisão em par | Unsafe/FFI complexo | Correção pequena rotineira |
| Bot LGTM + humano | Alto volume | Equipe apenas júnior |
| Revisão arquitetural | Novo serviço | Correção de erro de digitação |
FAQs
Quanto tempo deve levar a revisão?
Menos de 24 horas para PRs <400 linhas; o autor divide diffs maiores.
Autor auto-revisão?
Obrigatório: ler o diff no GitHub antes de solicitar revisão.
Quando envolver segurança?
Autenticação, criptografia, unsafe, novos parsers de entrada externa, dependência com aviso.
Relacionado
Versões da pilha: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4 e Polars 0.46+.