Busque em todas as páginas da documentação
A revisão de código é o principal ciclo de ensino da equipe para o ofício em Rust: propriedade, armadilhas assíncronas, limites de unsafe, e lacunas de teste. Uma cultura de alto sinal significa padrões claros, feedback respeitoso e retorno previsível - não um perfeccionismo que bloqueia a entrega.
Cartão de receita de referência rápida - pronto para copiar e colar.
## Modelo de descrição de PR
**Intenção:** uma frase
**Risco:** migração / perf / unsafe / segurança
**Evidência de teste:** `cargo test`, miri, nota de benchmark
**Rollback:** plano de sinalização ou reversão
## Níveis de comentários de revisão
🔴 Deve corrigir - correção, segurança, perda de dados
🟡 Deve corrigir - clareza, teste ausente (adiar com ticket OK)
🟢 Detalhe - estilo; a critério do autorQuando usar isso:
// Autor documenta trade-off intencional para revisores
// REVISÃO: manteve a leitura síncrona aqui - caminho somente leitura da fase 1 do RFC-042.
// Migração assíncrona para sqlx rastreada em ENG-4412.
pub async fn get_catalog_item(pool: &sqlx::PgPool, id: &str) -> Result<Item, AppError> {
let row = sqlx::query_as!(Item, "SELECT id, name FROM items WHERE id = $1", id)
.fetch_one(pool)
.await?;
Ok(row)
}# Checklist local do revisor
cargo test -p orders-api
cargo clippy -- -D warnings
# Se o PR tocar em unsafe:
cargo miri test -p ffi-bridgeO que isso demonstra:
unsafe acionam expectativas extras de CIunsafe documentados.rustfmt + clippy em CI - não debatido em revisão.cargo audit em alterações de dependência.unsafe/ e migrations/.rustfmt/clippy da equipe.unsafe - Correção: Política de governança exige dois aprovadores.| Alternativa | Usar Quando | Não Usar Quando |
|---|---|---|
| Programação em par em vez de revisão assíncrona | Refatoração complexa em andamento | Padrão de equipe distribuída |
| Bots de LGTM de pato de borracha | Apenas emergência | Barra de qualidade normal |
| Checklist de inspeção formal | Lançamentos regulamentados | Velocidade inicial de startup |
| Revisão pós-merge | Branch experimental | Branch main protegida |
Alvo <400 LOC de diff; fatias verticais superam despejos de camadas.
CODEOWNERS + um revisor de domínio; dois para unsafe e migrações.
Sem merge sem outro humano em branches protegidas.
Faça perguntas; sugira alternativas; evite "apenas" e críticas pessoais.
OK com link de ticket; o líder técnico rastreia a dívida no planejamento da sprint.
Obrigatório quando o autor alega melhoria de performance; delta do Criterion no PR.
Revise as entradas do gerador e os snapshots; não leia manualmente cada linha.
A equipe concorda com 24h; escalar na reunião diária se violado.
Link para documentação interna ou seção do livro Rust uma vez; evite threads de palestra.
Adicione um item de checklist ao modelo de PR se a classe de incidente foi perdida na revisão.
Versões da Stack: 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+.
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026