Introdução
Nasceu dentro do Extreme Programming (XP). É importante entender o contexto histórico dessa teoria.
Contexto Histórico
Nos anos 90, a cultura dominante de metologogia era o modelo cascata. Esse modelo exigia que se especificasse toda a arquitetura e requisitos antes de desenvolver qualquer linha de código, prevendo a necessidade futuras do sistema. O problema prático era: a equipe gastava meses construindo camadas de abstração, plugins configuráveis e ”flexibilidade” que nunca se materializavam, porque o mercado e os stakeholders mudavam de ideia mais rápido do que a arquitetura conseguia prever.
Definição do Princípio
Não implemente uma funcionalidade até que ela seja realmente necessária, nunca porque você acha que pode ser necessária no futuro.
Isso é diferente de “Não pensar no futuro”. YAGNI não é sobre ignorar arquitetura, é sobre adiar o custo de construção até o momento que o requisito real seja necessário.
Exemplos práticos de violação
- Criar um sistema de plugins genérico para "caso um dia precisemos suportar múltiplos provedores de pagamento", quando hoje só existe um provedor e nenhum contrato prevê outro.
- Adicionar campos "extras" ou tabelas de configuração no banco "para não precisar migrar depois", quando a migração de schema hoje é trivial e barata.
- Construir uma camada de abstração sobre uma biblioteca (ex: um wrapper genérico sobre o Axios "caso trocarmos de HTTP client") sem nenhuma indicação real de que essa troca vai acontecer.
- Implementar internacionalização (i18n) completa em um MVP que será testado só com usuários de um único país.
Como se relaciona com outros princípios
- KISS (Keep It Simple, Stupid): YAGNI é a aplicação temporal do KISS — simples agora, não simples "considerando tudo que pode vir".
- DRY (Don't Repeat Yourself): tensão real. DRY tenta eliminar duplicação abstraindo; YAGNI diz "não abstraia antes de ter 2-3 casos reais de repetição". Isso é onde nasce a regra prática "Rule of Three" (Martin Fowler / Don Roberts): só extraia uma abstração na terceira vez que o padrão aparecer, não na primeira.
- Refatoração contínua: YAGNI só funciona em conjunto com refatoração barata e testes automatizados. Se refatorar for caro no seu projeto, adiar decisões é arriscado — por isso XP empacotava YAGNI junto com TDD e integração contínua, não como prática isolada.
Top comments (0)