Ship it vs build it right: como equilibrar velocidade e qualidade

1. O Dilema Clássico: Entrega Rápida vs Código Robusto

No desenvolvimento de software, o conflito entre "ship it" e "build it right" é tão antigo quanto a própria indústria. De um lado, a pressão por entregar valor ao mercado o mais rápido possível — com MVPs, iterações curtas e protótipos funcionais. Do outro, a busca por arquiteturas limpas, testes abrangentes e código sustentável a longo prazo.

O custo real de cada extremo:

  • Ship it puro: acelera o time-to-market, mas acumula dívida técnica. Um estudo da Stripe estimou que desenvolvedores gastam 42% do tempo lidando com código mal escrito — o que custa US$ 85 bilhões anuais globalmente.
  • Build it right puro: gera código robusto, mas pode atrasar o lançamento em meses. Startups como a Webvan (entregas online) quebraram por investir demais em infraestrutura antes de validar o mercado.

O ponto ideal não está em nenhum dos extremos, mas em um equilíbrio dinâmico baseado em contexto.

2. Métricas para Decidir: Quando Acelerar e Quando Caprichar

Para tomar decisões conscientes, use critérios objetivos:

Critérios de decisão

Critério Ship it Build it right
Criticidade do sistema Baixa (página de marketing) Alta (processamento de pagamentos)
Impacto do erro Cosmético Perda financeira/dados
Frequência de mudanças Alta (experimento) Baixa (regra de negócio estável)

Matriz de decisão prática

Se (criticidade == ALTA E impacto == GRAVE) → Build it right
Se (criticidade == BAIXA E frequência == ALTA) → Ship it
Se (criticidade == MÉDIA) → Ship it com refactoring agendado

Ferramentas de medição

  • DORA metrics: deployment frequency, lead time, mean time to recovery, change failure rate
  • Indicadores de qualidade: cobertura de testes (>70% para crítico), duplicação de código (<5%), complexidade ciclomática (<10)

3. Estratégias de Equilíbrio: O Meio-Termo Inteligente

Entrega por camadas

Nem todo código merece o mesmo nível de rigor. Separe por contexto:

Camada 1 - Protótipos internos (ship it):
- Código descartável, sem testes, sem documentação
- Exemplo: prova de conceito para validar ideia com stakeholders

Camada 2 - Feature em produção controlada (meio-termo):
- Testes unitários nas funções críticas, linting básico
- Feature flags para desligar rapidamente se algo falhar

Camada 3 - Sistema crítico (build it right):
- Testes unitários, integração, contrato, E2E
- Documentação de arquitetura, code review obrigatório
- Design patterns e princípios SOLID

Técnica do "good enough"

Defina um padrão mínimo aceitável para cada camada:

# Exemplo de definição de padrão mínimo
# Para feature em produção controlada:
cobertura_testes >= 50%
testes_unitarios_para: [fluxo_principal, tratamento_erro_critico]
documentacao: [README com setup, changelog]
code_review: [1 aprovador, sem blockers de segurança]

Refactoring contínuo em pequenas doses

Em vez de parar a entrega para um grande refactor, reserve 20% do sprint para pagar dívida técnica:

Sprint atual:
- 80%: novas features (ship it com padrão mínimo)
- 20%: refactoring de código de sprints anteriores
  * Priorizar: funções com complexidade > 15, cobertura < 30%
  * Técnica: "scout rule" — deixe o código mais limpo do que encontrou

4. Cultura e Processo: Como a Equipe Define o Ritmo

Negociação de trade-offs

  • Product Owner: defende o valor de negócio e prazos
  • Tech Lead: defende a sustentabilidade técnica
  • Regra: toda decisão deve ser registrada com justificativa e data para revisão

Cerimônias ágeis que ajudam

  • Refinamento técnico: avalie complexidade e dívida técnica antes de estimar
  • Revisão de dívida técnica: a cada 2 sprints, revise o backlog técnico
  • Definition of Done flexível: o DoD pode variar por camada (ex.: protótipo não precisa de testes E2E)

Comunicação transparente

Em vez de "precisamos de mais tempo para qualidade", use:

"Essa feature tem 3 riscos técnicos identificados:
1. Dependência de sistema legado sem testes
2. Fluxo de pagamento com impacto financeiro
3. Time-to-market estimado em 2 semanas com testes completos

Sugestão: entregar em 1 semana com feature flag e testes apenas no fluxo crítico, 
completando o restante no sprint seguinte."

5. Ferramentas e Práticas para Acelerar sem Sacrificar Qualidade

Automação de qualidade

# pipeline de CI/CD com verificações automáticas
estágios:
  - lint:         eslint, prettier (falha se erros de estilo)
  - testes_unit:  jest com cobertura mínima de 50%
  - segurança:    npm audit, sonarcloud
  - build:        verifica se compila
  - deploy:       apenas se todos os estágios passarem

Feature flags e releases graduais

# Estrutura de feature flag
feature_flags:
  nova_busca:
    enabled: true
    rollout_percentage: 10  # 10% dos usuários
    kill_switch: true       # desligar instantaneamente se problema
    canary: true            # primeiro para servidores internos

Padrões de código que aceleram

  • Convention over Configuration: frameworks como Rails, Next.js, NestJS
  • Templates e scaffolds: geradores de CRUD, componentes base
  • Bibliotecas de componentes: evita recriar o básico

6. Casos Práticos: Exemplos de Decisões no Dia a Dia

Exemplo 1: Feature nova vs refactor de legado

Cenário: Sistema de autenticação legado com 80% de cobertura de testes
Solicitação: Adicionar login com Google

Decisão: Ship it com adaptador
- Criar adapter para Google Auth sem modificar o legado
- Testes unitários no adapter (90% cobertura)
- Refactor do legado agendado para próximo sprint
- Feature flag para desligar se problema

Exemplo 2: Hotfix urgente vs code review completo

Cenário: Bug crítico em produção — usuários não conseguem finalizar compra

Decisão: Ship it com pós-revisão
- Correção direta em produção (hotfix)
- Teste manual do fluxo principal
- Code review assíncrono em até 2 horas
- Rollback preparado caso algo falhe
- Teste unitário adicionado na sprint seguinte

Exemplo 3: API pública vs endpoint interno

Cenário: Mesma funcionalidade para API pública e endpoint interno

Decisão:
- API pública (build it right):
  * Testes de contrato, documentação OpenAPI
  * Rate limiting, validação de entrada rigorosa
  * Versionamento semântico

- Endpoint interno (ship it):
  * Apenas testes unitários básicos
  * Documentação no README
  * Sem versionamento — quebra controlada

7. Conclusão: O Equilíbrio como Habilidade Contínua

Não existe resposta certa universal. O equilíbrio entre "ship it" e "build it right" é um processo contínuo de decisão baseado em contexto.

Checklist prático para cada nova tarefa

Antes de começar, responda:

  1. Qual o impacto de um erro? (cosmético / financeiro / segurança)
  2. Quanto tempo temos? (horas / dias / semanas)
  3. Esse código será mantido por quanto tempo? (semanas / anos)
  4. Podemos reverter facilmente? (feature flag / rollback automático)
  5. Qual o custo de retrabalho? (baixo — refactor simples / alto — mudança arquitetural)

Se 3+ respostas apontarem para "ship it", vá rápido com padrão mínimo. Caso contrário, invista em qualidade.

Próximo passo: evolução da maturidade

  • Nível 1: Entrega rápida, dívida técnica alta
  • Nível 2: Entrega rápida com refactoring contínuo
  • Nível 3: Entrega rápida com qualidade automatizada
  • Nível 4: Entrega rápida com qualidade previsível (DORA metrics)

O objetivo não é escolher um lado, mas dominar a arte de navegar entre eles.

Referências