Noções Básicas de Liderança Técnica

9 exemplos para você começar com Liderança Técnica - 7 básicos e 2 intermediários.

Pré-requisitos

• Você é um engenheiro sênior ou um novo líder técnico em uma equipe Go com um módulo existente e pipeline de CI.
• Certifique-se de que a pasta docs/adr/ ou equivalente para decisões exista, ou crie-a em seu primeiro PR de liderança.
• Leia Liderança Técnica em Equipes Go para entender o escopo antes de executar estes exercícios.
• Tenha acesso para agendar uma revisão de design de 60 minutos e um bloco de mentoria recorrente no calendário.

Exemplos Básicos

1. Esboce um esqueleto mínimo de ADR

Capture uma decisão antes que a implementação se espalhe.

# ADR 0042: Usar errgroup para fan-out no worker de ingestão
 
## Status
Proposto
 
## Contexto
A ingestão fan-out hoje usa goroutines nuas; o desligamento descarta tarefas.
 
## Decisão
Usar golang.org/x/sync/errgroup com cancelamento de contexto em internal/ingest.
 
## Consequências
+ Retorno unificado de erro; - adiciona dependência de x/sync.

• ADRs precisam de status, contexto, decisão e consequências - não de diferenças de implementação.
• Numere sequencialmente; vincule a partir do README ou docs/adr/README.md.
• Mantenha como proposto até a reunião de revisão aprovar.

Relacionado: Escrevendo ADRs para Decisões de Arquitetura Go - modelos de ADR Go classificados

2. Indexe ADRs para onboarding

Torne as decisões descobertas sem arqueologia.

# Registros de Decisão de Arquitetura
 
| ID | Título | Status |
|----|-------|--------|
| 0042 | errgroup no worker de ingestão | Aceito |
| 0041 | Monolito de módulo único | Aceito |

• O índice é a primeira página que novos contratados leem após os padrões de codificação.
• Valores de status: Proposto, Aceito, Obsoleto, Substituído.
• Substitua em vez de excluir ADRs antigos.

Relacionado: Liderança Técnica em Equipes Go - por que ADRs ancoram a liderança

3. Execute uma agenda de revisão de design de 30 minutos

Limite o tempo da revisão antes de codificar um novo serviço.

## Revisão de Design - payments-api v2 (60m)
 
1. Metas / não-metas (5m)
2. Esboço da API + modelo de erro (15m)
3. Modelo de dados + migrações (10m)
4. Modelo de ameaças: authz, PII (15m)
5. Operabilidade: métricas, rollout (10m)
6. Itens de ação + necessidade de ADR? (5m)

• Envie o documento com 24 horas de antecedência; revisores comentam assincronamente quando possível.
• Registre os itens de ação no ticket, não apenas nas notas da reunião.
• Se a decisão criar um fork na arquitetura, abra um ADR antes do merge.

Relacionado: Revisões de Design para Serviços Go - playbook completo de revisão

4. Adicione um comentário de revisão que ensina

Substitua observações vagas por justificativas e links.

Considere envolver com %w para que os chamadores possam usar errors.Is para ErrNotFound.
Veja internal/errors/policy.md e ADR 0012.

• Comentários de ensino referenciam documentos da equipe, não gosto pessoal.
• Bloqueie em correção e operabilidade; adie o estilo para gofmt e linters.
• Se o mesmo comentário aparecer três vezes, promova para linter ou ADR.

Relacionado: Mentoria de Desenvolvedores Go em Diferentes Níveis de Experiência - ensinando através da revisão

5. Agende um bloco de mentoria semanal

Proteja o tempo para crescimento estruturado.

## Mentoria - Alex (intermediário) - Terças-feiras 30m
 
Semana 1: testes baseados em tabela em internal/pricing
Semana 2: propagação de contexto em handlers
Semana 3: co-revisão de PR de concorrência

• Agenda supera "horários de atendimento" em aberto para transferência de habilidades.
• Vincule cada bloco a um pequeno artefato: PR de teste, nota de documento ou revisão.
• Rotacione tópicos com base nas lacunas do guia de níveis.

Relacionado: Mentoria de Desenvolvedores Go em Diferentes Níveis de Experiência - planos específicos por nível

6. Registre um item de débito técnico com impacto

Torne a dívida legível para parceiros de produto.

## Débito: backlog golangci-lint staticcheck (42 issues)
 
Impacto: ruído de CI esconde defeitos reais; novos contratados copiam padrões suprimidos.
Custo: 2 dias de engenheiro
Proposta: queimar no sprint 12 com 20% de capacidade
Proprietário: @lead

• Tickets de débito precisam de impacto no cliente ou na velocidade, não apenas "limpeza".
• Tamanho em dias para que o planejamento possa negociar contra recursos.
• Atribua um proprietário; dívida sem dono nunca é enviada.

Relacionado: Backlogs de Débito Técnico para Bases de Código Go - framework de priorização

7. Facilite um desacordo com tempo limitado

Feche um debate de idiomatismos com um resultado registrado.

## Decisão: roteador HTTP para notificações (45m)
 
Opções: stdlib ServeMux vs chi
Critérios: necessidades de middleware, política somente stdlib, familiaridade da equipe
Decisão: chi apenas para notificações; ADR 0043 documenta a exceção
Data de revisão: 2026-Q4

• Liste opções, critérios, decisão e data de revisão no ticket.
• Uma exceção documentada supera forks silenciosos por serviço.
• Escalone apenas quando os critérios conflitarem com a política da empresa.

Relacionado: Lidando com Desacordos Técnicos em Equipes Go - padrões de facilitação

Exemplos Intermediários

8. Planeje uma atualização menor do Go com notas de raio de explosão

Lidere a mudança de ferramenta em vários serviços.

go mod edit -go=1.26
go test ./...
go fix ./...
golangci-lint run ./...

## Plano de atualização Go 1.25 -> 1.26
 
- Imagens de CI: atualizar .github/workflows + Dockerfile
- Notável: GC padrão Green Tea; executar teste de carga no checkout
- Rollback: reverter tag da imagem; diretiva go do go.mod inalterada até ficar verde

• Execute go test e linters em todos os módulos afetados.
• Observe as mudanças de comportamento (GC, verificações vet) no documento de rollout.
• Emparelhe a atualização com um bloco de horário de atendimento para perguntas da equipe.

Relacionado: Backlogs de Débito Técnico para Bases de Código Go - débito de módulo e de ferramenta

9. Defina o charter de iniciativa de escopo de staff

Amplie a influência sem perder a responsabilidade pela entrega.

## Charter: biblioteca de middleware HTTP compartilhada
 
Problema: métricas de autenticação duplicadas em 4 serviços
Sucesso: 3 serviços migrados; testes de middleware dourados em CI
Não-metas: substituição de framework; container DI para toda a organização
Patrocinador: TL de plataforma; Cronograma: Q3

• O trabalho no estilo de staff requer problema, métricas de sucesso e não-metas explícitas.
• Entregue uma implementação de referência que os consumidores possam copiar.
• Meça a adoção, não apenas as linhas de código compartilhado.

Relacionado: Caminho do Engenheiro de Staff em Organizações Go - expectativas de escopo e influência

Versões da Stack: Esta página foi escrita para Go 1.26.x (padrão Green Tea GC, modernizadores go fix - verifique o patch na compilação), chi (mais recente - verifique na compilação), gin (mais recente - verifique na compilação), echo (mais recente - verifique na compilação), google.golang.org/grpc (mais recente - verifique na compilação), sigs.k8s.io/controller-runtime (mais recente - verifique na compilação), kubebuilder (mais recente - verifique na compilação), tinygo (mais recente - verifique os alvos de placa na compilação), wazero (mais recente - verifique na compilação) e golangci-lint (mais recente - verifique o conjunto de linters na compilação).