Lidando com Desacordos Técnicos em Equipes Go

Padrões de facilitação para debates de idiomatismos versus frameworks.

Equipes Go discutem sobre o tipo certo de coisas: stdlib versus roteadores, generics versus interfaces, monolito versus módulos, errgroup versus canais.

Desacordos saudáveis melhoram designs.

Desacordos não facilitados se tornam serviços incompatíveis e threads de revisão amargos.

Resumo

Desacordos técnicos em equipes Go geralmente envolvem trade-offs entre simplicidade, velocidade e familiaridade operacional.

Facilitação significa tornar as opções explícitas, pontuar contra critérios acordados, designar um responsável pela decisão e registrar os resultados em ADRs ou padrões de equipe.

O objetivo não é o entusiasmo unânime.

É discordar e comprometer com uma data de revisão quando os dados puderem mudar a decisão.

Receita

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

## Decisão técnica: <tópico>
 
Opções:
1. ...
2. ...
 
Critérios (ponderados):
- operabilidade
- familiaridade da equipe
- tempo de compilação/implantação
- consistência com o índice de ADRs
 
Responsável pela decisão: @nome
Prazo: <data>
Revisão de fallback: <trimestre>

Quando usar isso:

Revisão dividida sobre mesclar chi vs stdlib mux
Plataforma exige apenas stdlib; squad quer bindings gin
Engenheiros seniores em impasse sobre layout de pacotes
Proposta de staff conflita com autonomia do squad
Reversões repetidas na mesma escolha arquitetural

Exemplo de Trabalho

Dois seniores discordam sobre concorrência de workers: canais vs errgroup.

## Registro de decisão (saída da reunião)
 
Tópico: orquestração de workers de ingestão
Opções:
A) errgroup + SetLimit
B) canal de pool de workers + goroutines fixas
 
Pontuações dos critérios (1-5):
| Critério | A | B |
|---|---|---|
| Clareza de shutdown | 5 | 3 |
| Familiaridade da equipe | 4 | 4 |
| Testabilidade | 5 | 4 |
 
Decisão: A para o novo worker de ingestão; B permanece no faturamento legado até que ADR 0031 seja substituído
Responsável: @tl
Revisão: após teste de carga do Q3

// Snippet de referência acordado para a opção A
g, ctx := errgroup.WithContext(ctx)
g.SetLimit(8)
for _, job := range batch {
    g.Go(func() error { return process(ctx, job) })
}
return g.Wait()

O que isso demonstra:

Opções nomeadas antes que o debate reabra detalhes de implementação
Tabela de critérios torna preferências subjetivas discutíveis
Exceção legada documentada em vez de padrões duplos silenciosos
Snippet de referência alinha futuros PRs

Análise Profunda

Como Funciona

O Tech Lead agenda uma sessão de decisão de 45 minutos com o documento circulado com antecedência.
Cada defensor escreve uma página: descrição da opção, riscos, custo de migração.
O grupo pontua os critérios; o responsável pela decisão escolhe, a menos que o limite de escalonamento seja atingido.
O resultado é registrado no ticket + ADR quando é cross-service; os revisores aplicam em PRs.

Padrões Comuns de Debate em Go

Debate	Tensão subjacente	Dica de facilitação
stdlib vs chi/gin	Consistência vs DX	Padrão da organização + exceções documentadas
generics vs interfaces	Clareza vs abstração	Prototipe ambos no mesmo esboço de API
monolith vs micro-módulo	Velocidade de compilação vs autonomia	Meça o churn de tags antes da divisão
sync vs async worker	Latência vs complexidade	Teste de carga antes de escolher canais
slog vs zap	Stdlib vs ecossistema	Escolha por ADR de observabilidade

Notas de Go

// Ao debater bibliotecas de erro, comece com a stdlib primeiro
if errors.Is(err, ErrNotFound) {
    return mapNotFound()
}

Prefira decisões que reduzam o fan-out de importação e o magic init.
Encare a adoção de frameworks como custo de dependência + treinamento, não gosto.
Use linters para codificar padrões acordados (depguard banindo imports).

Armadilhas

Debate em comentários de PR - Correção: Pause o PR; execute o template de decisão; retome com o link do ADR.
Consenso necessário - Correção: Nomeie o responsável pela decisão; escale para staff/arquiteto se necessário.
Sem data de revisão - Correção: Agende uma revisita trimestral quando as métricas puderem mudar de ideia.
O vencedor leva tudo - Correção: Permita migração faseada para caminhos legados com ADR de sunset.
Argumentos apenas de autoridade - Correção: Exija pontuações de critérios e dados (latência, LOC, incidentes).
Resmungos silenciosos após a decisão - Correção: Documente a dissidência na seção "Notas" do ADR; comprometa-se mesmo assim.

Alternativas

Alternativa	Use Quando	Não Use Quando
Spike ambas as opções	Evidência fraca	Decisão bloqueia várias equipes por semanas
Escalar para conselho de arquitetos	Impacto cross-org	Estilo de manipulador local do squad
Padrão para minimalismo stdlib	Sem dados, pontuações iguais	Framework claramente economiza semanas
Adiar decisão	Fork de baixo impacto	Escolha de concorrência em produção

FAQs

Quem deve ser o responsável pela decisão final?

Tech Lead para escopo do squad; staff/plataforma para padrões cross-cutting; diretor de engenharia para exceções de política.

Quanto tempo os debates devem durar?

Uma sessão focada mais comentários assíncronos no documento - geralmente menos de uma semana para decisões de squad.

E se duas opções pontuarem igualmente?

Escolha o padrão da organização (geralmente simplicidade stdlib) e defina uma data de revisão após o próximo benchmark ou lançamento.

A dissidência deve ser registrada?

Sim, nas notas do ADR - ajuda futuros revisores a entenderem o contexto sem reabrir a briga.

Como lidar com desacordos públicos no Slack?

Mova para a thread do documento de decisão; mantenha o Slack para fatos, não para enquetes que contornam os critérios.

Quando a escalada é apropriada?

Quando a decisão afeta SLOs, postura de segurança ou os gráficos de módulos de várias equipes.

As equipes podem substituir ADRs da plataforma?

Apenas com um ADR substituto aprovado pelo proprietário da plataforma - não exceções locais no README.

Como prevenir o fanatismo de idiomatismos versus frameworks?

Meça os resultados: contagem de incidentes, tempo de revisão, semanas de onboarding - não slogans.

E quanto à forte dissidência de juniores?

Bem-vindo à contribuição de critérios; o responsável pela decisão ainda decide com escopo apropriado ao nível.

Devemos votar?

Use a pontuação de critérios em vez de votos brutos - a popularidade perde as restrições de operabilidade.

Como revisitar uma decisão resolvida?

Traga novos dados para a data de revisão ou arquive um ADR substituto com plano de migração.

O "discordar e comprometer" se aplica a questões de segurança?

Não - bloqueie riscos de segurança, perda de dados ou race conditions, independentemente do resultado do processo.

Relacionados

Liderança Técnica em Equipes Go - responsabilidade da liderança pela facilitação
Noções Básicas de Liderança Técnica - template de desacordo com tempo limitado
Escrevendo ADRs para Decisões de Arquitetura Go - registre resultados
Revisões de Design para Serviços Go - previna desacordos tardios
Cultura de Revisão de Código para Go - mantenha debates fora das threads de detalhes

Versões da 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).

Equipes Go discutem sobre o tipo certo de coisas: stdlib versus roteadores, generics versus interfaces, monolito versus módulos, errgroup versus canais.

Desacordos saudáveis melhoram designs.

Desacordos não facilitados se tornam serviços incompatíveis e threads de revisão amargos.

Resumo

Desacordos técnicos em equipes Go geralmente envolvem trade-offs entre simplicidade, velocidade e familiaridade operacional.

Facilitação significa tornar as opções explícitas, pontuar contra critérios acordados, designar um responsável pela decisão e registrar os resultados em ADRs ou padrões de equipe.

O objetivo não é o entusiasmo unânime.

É discordar e comprometer com uma data de revisão quando os dados puderem mudar a decisão.

Receita

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

## Decisão técnica: <tópico>
 
Opções:
1. ...
2. ...
 
Critérios (ponderados):
- operabilidade
- familiaridade da equipe
- tempo de compilação/implantação
- consistência com o índice de ADRs
 
Responsável pela decisão: @nome
Prazo: <data>
Revisão de fallback: <trimestre>

Quando usar isso:

Revisão dividida sobre mesclar chi vs stdlib mux
Plataforma exige apenas stdlib; squad quer bindings gin
Engenheiros seniores em impasse sobre layout de pacotes
Proposta de staff conflita com autonomia do squad
Reversões repetidas na mesma escolha arquitetural

Exemplo de Trabalho

Dois seniores discordam sobre concorrência de workers: canais vs errgroup.

## Registro de decisão (saída da reunião)
 
Tópico: orquestração de workers de ingestão
Opções:
A) errgroup + SetLimit
B) canal de pool de workers + goroutines fixas
 
Pontuações dos critérios (1-5):
| Critério | A | B |
|---|---|---|
| Clareza de shutdown | 5 | 3 |
| Familiaridade da equipe | 4 | 4 |
| Testabilidade | 5 | 4 |
 
Decisão: A para o novo worker de ingestão; B permanece no faturamento legado até que ADR 0031 seja substituído
Responsável: @tl
Revisão: após teste de carga do Q3

// Snippet de referência acordado para a opção A
g, ctx := errgroup.WithContext(ctx)
g.SetLimit(8)
for _, job := range batch {
    g.Go(func() error { return process(ctx, job) })
}
return g.Wait()

O que isso demonstra:

Opções nomeadas antes que o debate reabra detalhes de implementação
Tabela de critérios torna preferências subjetivas discutíveis
Exceção legada documentada em vez de padrões duplos silenciosos
Snippet de referência alinha futuros PRs

Análise Profunda

Como Funciona

O Tech Lead agenda uma sessão de decisão de 45 minutos com o documento circulado com antecedência.
Cada defensor escreve uma página: descrição da opção, riscos, custo de migração.
O grupo pontua os critérios; o responsável pela decisão escolhe, a menos que o limite de escalonamento seja atingido.
O resultado é registrado no ticket + ADR quando é cross-service; os revisores aplicam em PRs.

Padrões Comuns de Debate em Go

Debate	Tensão subjacente	Dica de facilitação
stdlib vs chi/gin	Consistência vs DX	Padrão da organização + exceções documentadas
generics vs interfaces	Clareza vs abstração	Prototipe ambos no mesmo esboço de API
monolith vs micro-módulo	Velocidade de compilação vs autonomia	Meça o churn de tags antes da divisão
sync vs async worker	Latência vs complexidade	Teste de carga antes de escolher canais
slog vs zap	Stdlib vs ecossistema	Escolha por ADR de observabilidade

Notas de Go

// Ao debater bibliotecas de erro, comece com a stdlib primeiro
if errors.Is(err, ErrNotFound) {
    return mapNotFound()
}

Prefira decisões que reduzam o fan-out de importação e o magic init.
Encare a adoção de frameworks como custo de dependência + treinamento, não gosto.
Use linters para codificar padrões acordados (depguard banindo imports).

Armadilhas

Debate em comentários de PR - Correção: Pause o PR; execute o template de decisão; retome com o link do ADR.
Consenso necessário - Correção: Nomeie o responsável pela decisão; escale para staff/arquiteto se necessário.
Sem data de revisão - Correção: Agende uma revisita trimestral quando as métricas puderem mudar de ideia.
O vencedor leva tudo - Correção: Permita migração faseada para caminhos legados com ADR de sunset.
Argumentos apenas de autoridade - Correção: Exija pontuações de critérios e dados (latência, LOC, incidentes).
Resmungos silenciosos após a decisão - Correção: Documente a dissidência na seção "Notas" do ADR; comprometa-se mesmo assim.

Alternativas

Alternativa	Use Quando	Não Use Quando
Spike ambas as opções	Evidência fraca	Decisão bloqueia várias equipes por semanas
Escalar para conselho de arquitetos	Impacto cross-org	Estilo de manipulador local do squad
Padrão para minimalismo stdlib	Sem dados, pontuações iguais	Framework claramente economiza semanas
Adiar decisão	Fork de baixo impacto	Escolha de concorrência em produção

FAQs

Quem deve ser o responsável pela decisão final?

Tech Lead para escopo do squad; staff/plataforma para padrões cross-cutting; diretor de engenharia para exceções de política.

Quanto tempo os debates devem durar?

Uma sessão focada mais comentários assíncronos no documento - geralmente menos de uma semana para decisões de squad.

E se duas opções pontuarem igualmente?

Escolha o padrão da organização (geralmente simplicidade stdlib) e defina uma data de revisão após o próximo benchmark ou lançamento.

A dissidência deve ser registrada?

Sim, nas notas do ADR - ajuda futuros revisores a entenderem o contexto sem reabrir a briga.

Como lidar com desacordos públicos no Slack?

Mova para a thread do documento de decisão; mantenha o Slack para fatos, não para enquetes que contornam os critérios.

Quando a escalada é apropriada?

Quando a decisão afeta SLOs, postura de segurança ou os gráficos de módulos de várias equipes.

As equipes podem substituir ADRs da plataforma?

Apenas com um ADR substituto aprovado pelo proprietário da plataforma - não exceções locais no README.

Como prevenir o fanatismo de idiomatismos versus frameworks?

Meça os resultados: contagem de incidentes, tempo de revisão, semanas de onboarding - não slogans.

E quanto à forte dissidência de juniores?

Bem-vindo à contribuição de critérios; o responsável pela decisão ainda decide com escopo apropriado ao nível.

Devemos votar?

Use a pontuação de critérios em vez de votos brutos - a popularidade perde as restrições de operabilidade.

Como revisitar uma decisão resolvida?

Traga novos dados para a data de revisão ou arquive um ADR substituto com plano de migração.

O "discordar e comprometer" se aplica a questões de segurança?

Não - bloqueie riscos de segurança, perda de dados ou race conditions, independentemente do resultado do processo.

Relacionados

Liderança Técnica em Equipes Go - responsabilidade da liderança pela facilitação
Noções Básicas de Liderança Técnica - template de desacordo com tempo limitado
Escrevendo ADRs para Decisões de Arquitetura Go - registre resultados
Revisões de Design para Serviços Go - previna desacordos tardios
Cultura de Revisão de Código para Go - mantenha debates fora das threads de detalhes

Versões da 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).

Lidando com Desacordos Técnicos em Equipes Go

Buscar na documentação

Lidando com Desacordos Técnicos em Equipes Go