Melhores Práticas de Equipe
Um resumo condensado das 25 práticas de equipe mais importantes que mantêm uma equipe de engenharia Python ágil, alinhada e gentil - extraído de todas as páginas desta seção.
//
Busque em todas as páginas da documentação
Um resumo condensado das 25 práticas de equipe mais importantes que mantêm uma equipe de engenharia Python ágil, alinhada e gentil - extraído de todas as páginas desta seção.
Tempo para o primeiro PR é a métrica: PR pequeno mesclado até o quinto dia - mede a saúde do onboarding e das ferramentas (Checklist de Onboarding de Desenvolvedores).
Um documento de onboarding canônico: Vinculado do README com proprietário nomeado e data da última revisão.
Dupla para a primeira semana: Colega nomeado, check-in diário de 15 minutos - não "pergunte à equipe".
Configuração do ambiente é roteirizada: uv sync, pytest, /health documentados em Checklist de Configuração de Ambiente.
Comandos de CI executados localmente: O mesmo ruff/pytest/mypy do GitHub Actions antes do push.
.env.example sempre atualizado: Cada novo campo de configuração atualiza o exemplo sem segredos.
CODEOWNERS em caminhos sensíveis: Migrações, autenticação, pagamentos solicitam automaticamente especialistas.
ADRs para decisões não óbvias: Estratégia de framework, schema e flags registradas em docs/adr/.
Rastreie uma requisição na primeira semana: Mais rápido do que ler a árvore inteira (Orientação da Base de Código).
Convenções na configuração do ruff: Debates de estilo terminam em pyproject.toml, não em comentários de revisão (Guia de Convenções e Estilo).
ID do ticket em cada commit: Cherry-picks e automação de changelog dependem disso.
Modelo de descrição de PR: Nota de migração, plano de teste, rollback - campos obrigatórios.
Revise os testes antes da implementação: Revisores validam a mudança de comportamento por meio de asserções.
Comentários de revisão específicos e gentis: Perguntas e sugestões, não "apenas corrija" sem contexto (Diretrizes de Revisão de Código).
Aprove quando a barra for atingida: Não bloqueie por preferência quando o CI estiver verde e os P0/P1 satisfeitos.
Pequenos PRs como padrão: Divida quando a diferença for > ~400 linhas ou envolver preocupações mistas.
Transferências internas recebem onboarding: Sênior para novo subsistema ainda precisa de acesso e tour de arquitetura.
PRs de documentação de novos contratados são celebrados: O primeiro PR corrigindo um erro de digitação no onboarding é um sinal de sucesso.
Atualizações de documentação pós-incidente: Cada sev2+ atualiza o runbook ou item de checklist.
Retrospectivas sem culpa: Foco em sistemas - atualize checklists, não indivíduos.
Alvos compartilhados de shell/Makefile: make test, make lint documentados para todos os repositórios.
Sem heroísmo no deploy: Siga o checklist; sinalize lacuna no processo se for necessário um atalho.
Rotacione o plantão com sombra: Novos contratados fazem sombra antes de assumir o pager sozinhos.
Higiene trimestral de dependências: Itens de sprint agendados para atualizações menores de CVE e Python.
Normas da equipe por escrito: Regras não escritas se tornam gatekeeping - publique e revise abertamente.
Adicione horas explícitas de sobreposição, tours de arquitetura gravados e logs de decisão escritos em threads do Slack vinculados a ADRs.
Um ticket, uma preocupação, revisável em 30 minutos - não apenas uma única linha, a menos que o teste precise de contexto.
Prefira um colega como dupla para segurança psicológica; o gerente participa do checkpoint da segunda semana.
Mesma barra de revisão e segurança; esclareça a entrega de propriedade no final do contrato.
Versões da Stack: Esta página foi escrita para Python 3.14.0 (estável 3.14, manutenção 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+ e uv 0.6+.
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026