Cultura de Revisão de Código

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.

Receita

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 autor

Quando usar isso:

• A latência de revisão excede 24 horas rotineiramente
• As revisões são guerras de estilo sem ensino
• Juniores temem postar PRs
• Incidentes rastreiam verificações de revisão perdidas

Exemplo de Trabalho

// 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-bridge

O que isso demonstra:

• O autor vincula o trabalho adiado a um ticket, reduzindo o re-debate
• Os revisores executam portões automatizados localmente; humanos focam no design
• PRs unsafe acionam expectativas extras de CI

Mergulho Profundo

O que Revisar em Rust

• Correção - Tratamento de erros, limites, invariantes unsafe documentados.
• Operabilidade - Logs, métricas, política de pânico no caminho crítico.
• Design de API - A superfície pública do crate segue as diretrizes de API do Rust.
• Testes - Caminho feliz + um modo de falha; testes de propriedade para parsers.
• Escopo - O PR corresponde à intenção declarada; refatores de última hora separados.

Normas de Retorno

• Primeira resposta < 24h em horário comercial.
• LGTM com detalhes é válido; o autor escolhe os detalhes.
• Escalar desacordo bloqueador para o líder técnico após 2 rodadas.

Automação

• rustfmt + clippy em CI - não debatido em revisão.
• cargo audit em alterações de dependência.
• CODEOWNERS para unsafe/ e migrations/.

Armadilhas

• LGTM sem ler testes - Correção: Exigir evidência de teste no modelo.
• Revisores apenas seniores - Gargalo. Correção: Rotacionar; juniores revisam documentação e testes.
• PR de 4000 linhas - Revisão superficial. Correção: Dividir por crate ou flag de funcionalidade.
• Bikeshedding de nomenclatura - Correção: Nível de detalhe; padrões rustfmt/clippy da equipe.
• Sem segundo revisor para unsafe - Correção: Política de governança exige dois aprovadores.

Alternativas

FAQs

Relacionado

• Mentoria e Nivelamento - crescer revisores
• Padrões de Codificação e Diretrizes de API - padrões
• Governança de Unsafe e Dependência - revisão de unsafe
• Melhores Práticas de Linting e Formatação - automatizar estilo
• Melhores Práticas de Liderança - resumo

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+.