Melhores Práticas de Liderança
Um resumo condensado das 25 práticas mais importantes de liderança técnica para especialistas em Rust - extraídas de todas as páginas desta seção.
//
Busque em todas as páginas da documentação
Um resumo condensado das 25 práticas mais importantes de liderança técnica para especialistas em Rust - extraídas de todas as páginas desta seção.
Escreva opções antes de defender uma: Trade-offs classificados evitam fanatismo por framework - Tomada de Decisão Técnica.
ADR para escolhas custosas de reverter: Framework, fila, DB, atualização de edição, política de unsafe.
Substitua ADRs, nunca delete: Trilha de auditoria e aprendizado preservados - Registros de Decisão de Arquitetura (ADRs).
RFC antes de grandes PRs: Esquema entre equipes e migrações assíncronas precisam de revisão de design - Realizando Revisões de Design.
Atribua revisores céticos e operadores: Teste de estresse e impacto on-call obrigatórios.
Reuniões de design com tempo limite de 45 minutos: Decida aceitar, revisar ou fazer um spike.
Vincule spikes a perguntas abertas de RFC: Evidências antes de guerras de opinião.
Modelo de PR inclui intenção e rollback: Revisores focam no risco - Cultura de Revisão de Código.
Níveis de comentário: deve corrigir, deveria corrigir, nit: Nits não são bloqueadores.
Automatize estilo com rustfmt/clippy em CI: Humanos revisam design e correção.
Rotacione revisores de código: Espalhe contexto; evite um único gatekeeper.
Pequenos PRs abaixo de 400 LOC: Revisão profunda supera diffs gigantes rasos.
Acompanhe novos contratados por 90 dias: Faça shadow no on-call antes de páginas solo - Mentoria e Nivelamento.
Rubrica de nivelamento com exemplos em Rust: Evidência de promoção é comportamental.
Reúna refatorações complexas semanalmente: Migrações e auditorias de unsafe.
Delegue resultados, não tarefas: O briefing inclui autoridade e restrições - Delegação e Disseminação de Contexto.
Rotacione o capitão de lançamento e CODEOWNERS: Reduza o fator ônibus trimestralmente.
Propriedade de módulo no README: O on-call sabe quem contatar.
Log de discordâncias no apêndice da RFC: "O que mudaria sua opinião" falseável.
Nomeie o tomador de decisão antecipadamente: Encerre threads de PR circulares - Lidando com Discordâncias Técnicas.
Spikes de 2-3 dias resolvem disputas de evidências: Critérios de sucesso binários são necessários.
Discorde e comprometa publicamente: Sem sabotagem passiva pós-decisão.
Registre dissidência nas consequências da ADR: Gatilhos de revisitados documentados.
IC decide durante SEV1: Debate de processo espera pelo post-mortem.
Proteja 10-20% do tempo de mentoria: Liderança sustentável supera heroísmo.
30-50% no início da equipe; 20-30% em escala - mantenha a credibilidade nas revisões de Rust.
O líder é responsável pela entrega da squad; o staff é responsável pela arquitetura entre frotas - os papéis podem se sobrepor.
Correção de bug em crate único e configuração reversível; não para esquema ou unsafe.
Não - o capitão de lançamento é rotativo; o líder revisa exceções e tendências de CFR.
O EM é responsável pelas pessoas e cronograma; o líder é responsável pelo padrão técnico - escale conjuntamente ao diretor se estiver travado.
RFCs escritas, resumos de design gravados, logs de decisão explícitos.
CFR, latência de revisão, métrica de fator ônibus, saúde do pipeline de promoção.
Rotacione; o líder treina o IC, não assume o modo herói por padrão.
Duas squads ou >10 engenheiros em uma área de produto.
Quinzenal opcional; compartilha incidentes, crates e aprendizados de ADR em toda a frota.
Versões de 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