YAGNI: O princípio que evita código desnecessário e arquiteturas complexas

É justamente contra esse tipo de desperdício que surge o YAGNI.

Seu nome vem da expressão You Aren't Gonna Need It, que pode ser traduzida como "Você não vai precisar disso". O princípio nasceu dentro da metodologia Extreme Programming (XP), criada por Kent Beck, e defende uma ideia simples:

Implemente apenas aquilo que é necessário hoje. O restante deve esperar até existir uma necessidade real.

Embora pareça um princípio voltado apenas para programação, o YAGNI influencia decisões de arquitetura, design, modelagem de banco de dados e até planejamento de produto.

A origem do YAGNI

O conceito surgiu durante o desenvolvimento do projeto C3, onde Kent Beck frequentemente respondia às sugestões de implementar funcionalidades futuras com a frase:

"You aren't gonna need it."

Com o tempo, essa frase tornou-se um dos pilares do Extreme Programming (XP), incentivando equipes a evitar funcionalidades especulativas e focar na entrega contínua de valor.

O problema da programação especulativa

Imagine que você esteja desenvolvendo um sistema de autenticação.

Hoje, a única necessidade é login utilizando e-mail e senha.

Mesmo assim, você pensa:

• Talvez no futuro exista login com Google;
• Talvez exista login com Microsoft;
• Talvez exista autenticação LDAP;
• Talvez exista autenticação via SAML.

Então você cria uma arquitetura extremamente flexível.

AuthProvider
├── EmailProvider
├── GoogleProvider
├── MicrosoftProvider
├── FacebookProvider
├── LdapProvider
└── SamlProvider

Depois de um ano, o sistema continua utilizando apenas login por e-mail.

Todo o restante do código:

• nunca foi utilizado;
• precisou ser mantido;
• aumentou a complexidade;
• aumentou o tempo de desenvolvimento.

Isso é exatamente o que o YAGNI procura evitar.

Como aplicar o YAGNI

O princípio é bastante simples:

Resolva apenas o problema atual.

Se hoje existe apenas uma forma de autenticação, implemente apenas essa.

Quando surgir uma nova necessidade, evolua a solução através de refatoração.

Em vez de pensar:

"E se um dia precisarmos disso?"

Pergunte:

"Existe algum requisito que exija isso hoje?"

Se a resposta for não, provavelmente essa implementação pode esperar.

Exemplos práticos

Exemplo 1 — Interface desnecessária

Errado:

interface PaymentGateway {
  process(): void
}

Com apenas uma implementação:

PixGateway

Não existe benefício em criar uma abstração quando há apenas um caso concreto.

Melhor solução:

class PixGateway {
  process() {}
}

Quando surgir um segundo gateway (cartão, boleto etc.), aí sim faz sentido extrair uma interface.

Exemplo 2 — Microserviços prematuros

Imagine uma startup com apenas dois desenvolvedores.

Mesmo assim, o projeto nasce dividido em:

• Auth Service
• User Service
• Payment Service
• Notification Service
• Inventory Service

Tudo rodando em Kubernetes.

Enquanto isso, o sistema possui apenas cinco telas.

Essa arquitetura provavelmente viola o YAGNI.

Um monólito modular seria muito mais simples, barato e fácil de manter.

Exemplo 3 — React

Você precisa apenas de um botão.

Em vez disso cria:

<Button
  variant="primary"
  animation
  loading
  rounded
  iconLeft
  iconRight
  elevation
  size="xl"
/>

Mesmo que o projeto utilize apenas:

<Button>
  Salvar
</Button>

Esse tipo de excesso aumenta a complexidade sem gerar valor.

YAGNI não significa escrever código descartável

Um erro bastante comum é interpretar o princípio como:

"Faça qualquer coisa, depois você resolve."

Não é isso.

Você deve escrever código com qualidade:

• nomes claros;
• responsabilidades bem definidas;
• testes;
• baixo acoplamento;
• boa legibilidade.

A diferença é que você não implementa funcionalidades ou abstrações sem necessidade comprovada.

O próprio Kent Beck ressalta que o YAGNI é uma questão de timing, não um argumento contra design ou arquitetura.

Benefícios do YAGNI

Aplicar esse princípio gera diversas vantagens:

• código menor;
• menor custo de manutenção;
• menos bugs;
• entregas mais rápidas;
• menos testes desnecessários;
• arquitetura mais simples;
• menor custo de evolução.

Além disso, sistemas menores costumam ser muito mais fáceis de compreender por novos desenvolvedores.

Quando o YAGNI não deve ser aplicado?

O YAGNI não significa ignorar requisitos conhecidos.

Se existe uma demanda aprovada para o próximo mês, faz sentido preparar a arquitetura.

Da mesma forma, requisitos não funcionais conhecidos também precisam ser considerados desde o início, como:

• alta disponibilidade;
• escalabilidade prevista;
• requisitos legais;
• segurança;
• auditoria.

O erro está em desenvolver funcionalidades para cenários puramente hipotéticos.

YAGNI x KISS x DRY x SOLID

Esses princípios são frequentemente utilizados juntos.

YAGNI -> Não implemente funcionalidades antes de elas serem necessárias.

KISS -> Escolha sempre a solução mais simples que resolva o problema.

DRY -> Evite duplicação de conhecimento e lógica.

SOLID -> Produza um software flexível, coeso e de fácil manutenção.

O YAGNI complementa os demais ao impedir que abstrações prematuras tornem o sistema mais complexo do que o necessário.

Conclusão

O YAGNI é um lembrete de que a maioria das previsões sobre o futuro de um software está errada. Em vez de gastar tempo implementando funcionalidades que talvez nunca sejam usadas, concentre-se em entregar valor agora, mantendo o código simples e preparado para evoluir por meio de refatorações.

Arquiteturas elegantes não são aquelas que resolvem todos os problemas imagináveis, mas sim as que resolvem muito bem os problemas atuais e conseguem evoluir conforme novas necessidades surgem.

Como costuma acontecer em engenharia de software, a simplicidade quase sempre é a decisão mais difícil — e também a mais valiosa.

Saiba mais

Martin Fowler — YAGNI — Explicação detalhada do princípio, sua origem e exemplos de aplicação.

Martin Fowler — Extreme Programming — Introdução à metodologia XP e às práticas que deram origem ao YAGNI.

Martin Fowler — Beck Design Rules — As quatro regras de design simples propostas por Kent Beck.