Sessões de Pair & Mob para Equipes Go

Padrões de transferência de conhecimento para idiomas e concorrência.

Idiomas Go são aprendidos através de loops de feedback em código real.

Pair programming e mob programming estruturados comprimem meses de tentativa e erro em sessões focadas que também disseminam a cultura de revisão.

Resumo

Pair programming e mob programming são formatos deliberados para compartilhar hábitos de toolchain, padrões de tratamento de erros e julgamento de revisão de concorrência.

Eles complementam caminhos de leitura e checklists com explicação ao vivo do porquê um revisor bloquearia um PR.

Sessões curtas com agendas claras superam o compartilhamento de tela não estruturado.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

## Pair de onboarding de 90 minutos (modelo)
 
1. (15m) Navigator percorre o layout do módulo + README de CI
2. (25m) Driver corrige um problema do golangci-lint com orientação do navigator
3. (25m) Leitura conjunta de um caminho de código concorrente; execute `go test -race`
4. (15m) Debrief: três idiomas para aplicar + um PR para abrir antes da próxima sessão
5. (10m) Agende a próxima sessão + atribua link de pré-leitura

Quando usar isso:

• Primeiras duas semanas de onboarding em Go para contratados experientes
• Antes do primeiro PR de um engenheiro com muita concorrência
• Após um incidente para reproduzir a linha do tempo e os testes
• Quando os comentários de revisão repetem a mesma lacuna de idioma em vários autores

Exemplo de Trabalho

Uma equipe executa um mob de concorrência semanal em um bug de staging: contagem elevada de goroutines após o deploy.

// O Mob examina este padrão em conjunto - o driver compartilha a tela
func (s *Service) poll(ctx context.Context) error {
    for {
        select {
        case <-ctx.Done():
            return ctx.Err()
        case <-time.After(time.Second):
            if err := s.tick(ctx); err != nil {
                return err
            }
        }
    }
}

// Resultado da refatoração que o mob visa - ticker com defer Stop
func (s *Service) poll(ctx context.Context) error {
    ticker := time.NewTicker(time.Second)
    defer ticker.Stop()
    for {
        select {
        case <-ctx.Done():
            return ctx.Err()
        case <-ticker.C:
            if err := s.tick(ctx); err != nil {
                return err
            }
        }
    }
}

O que isso demonstra:

• time.After em loops aloca timers; a correção idiomática usa NewTicker e Stop.
• O Mob lê métricas de produção primeiro, depois o código, e então escreve um teste de regressão.
• O Navigator pede ao driver para executar go test -race antes de mesclar a correção.
• As notas da sessão vinculam ao PR e atualizam um documento de "armadilhas" da equipe.

Mergulho Profundo

Como Funciona

• O Driver é quem opera o teclado; o Navigator faz perguntas, identifica erros perdidos e cita os padrões da equipe.
• O Mob se estende a 3+ pessoas com um driver rotativo em um timer; ideal para incidentes e explorações de design.
• As sessões devem terminar com artefatos: link do PR, atualização de checklist ou um item de ADR - não apenas acordo verbal.

Tipos de Sessão

Notas Go

// Exercício de Pairing: esqueleto de subteste baseado em tabela que os revisores esperam
func TestLimiter(t *testing.T) {
    cases := []struct {
        name string
        n    int
        want int
    }{
        {"zero", 0, 0},
        {"one", 1, 1},
    }
    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            if got := Limiter(tc.n); got != tc.want {
                t.Fatalf("got %d want %d", got, tc.want)
            }
        })
    }
}

Use exercícios como este quando o feedback da revisão disser "adicione casos", mas o autor ainda não viu testes exemplares em seu repositório.

Regras de Facilitação

• Alterne as funções a cada 20-30 minutos nos mobs.
• Silencie telefones; uma conversa por vez.
• Estacione refatores não relacionados em uma lista de "mais tarde" visível para o grupo.
• Prefira tarefas do repositório em vez de kata sintética após a primeira semana, para que os imports e a CI correspondam à realidade.

Armadilhas

• Mob sem limites e sem agenda - as sessões decaem em observação passiva. Correção: publique uma agenda de três pontos antes do convite do calendário.
• Sempre o mesmo sênior navegando - cria um ponto único de cultura de revisão. Correção: alterne os navigators mensalmente.
• Pular -race durante pairs de concorrência - contratados pensam que testes verdes significam concorrência segura. Correção: torne a execução do race um critério de saída da sessão.
• Sem acompanhamento escrito - insights morrem quando as pessoas mudam de tarefa. Correção: nota de debrief de dois minutos no ticket ou wiki.
• Pairing apenas com juniores - seniores também precisam de pairing ao lidar com domínios desconhecidos (operadores, WASM). Correção: agende pairs inter-níveis em novas stacks.
• Gravação sem consentimento - viola a política ou o conforto. Correção: pergunte explicitamente; o padrão é apenas notas escritas.

Alternativas

FAQs

Relacionados

• Onboarding de Especialistas Go - onde o pairing se encaixa nas camadas de rampa
• Noções Básicas de Onboarding de Equipe - exemplo de agenda de 9 pares
• Checklist de Onboarding de SME Go (30/60/90) - linhas de evidência de pairing
• Cultura de Revisão de Código para Go - normas que os pares devem ensinar
• Caminho de Leitura de Go Eficaz - espinha dorsal de pré-leitura entre sessões

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