O que é o principio YAGNI

YAGNI e a sigla de You Aren't Gonna Need It, algo como "você não vai precisar disso" em português. E um principio de engenharia de software que diz uma coisa simples: não implemente uma funcionalidade enquanto ela não for realmente necessária.

O termo nasceu no fim dos anos 1990, dentro da Extreme Programming (XP), a metodologia ágil criada por Kent Beck e Ron Jeffries. A ideia era combater um hábito comum entre desenvolvedores: escrever código hoje para resolver problemas que talvez apareçam no futuro. E muitas vezes esse futuro nunca chega.

O YAGNI voltou a ser assunto recentemente porque o próprio Kent Beck publicou reflexões sobre o que o principio sempre quis dizer de verdade. A discussão mostra que, depois de mais de duas décadas, muita gente ainda confunde "não construir o que não precisa" com "nunca pensar no amanha".

Como funciona na prática

O raciocínio por trás do YAGNI e económico. Todo código que você escreve tem um custo: tempo para criar, tempo para testar, tempo para entender depois e tempo para manter. Quando você escreve algo "por garantia", paga todos esses custos sem ter certeza de que vai colher algum beneficio.

Pense numa analogia: e como comprar moveis para um quarto extra de uma casa que você ainda nem decidiu se vai construir. Se o quarto nunca sair do papel, os moveis viram peso morto ocupando espaço e juntando poeira.

No código, esse peso morto e ainda pior, porque ele não fica parado. Funcionalidades especulativas precisam ser mantidas a cada mudança, confundem quem le o código e muitas vezes engessam decisões futuras com base em palpites que se mostraram errados.

Principais ideias por trás do YAGNI

O YAGNI não e uma regra isolada. Ele se apoia em alguns pilares que ajudam a entender quando aplica-lo:

  • Custo de carregar código: manter algo que existe custa caro ao longo do tempo, mesmo que tenha sido barato de escrever.
  • Custo de adiar: em geral e mais barato adicionar uma funcionalidade quando ela for necessária do que carregar uma errada por meses.
  • Incerteza do futuro: nossas previsões sobre o que o sistema vai precisar costumam falhar. Quanto mais cedo a decisão, menos informação você tem.
  • Design simples: sistemas mais enxutos são mais fáceis de mudar quando a necessidade real aparece.

A grande sacada de Kent Beck e que o YAGNI nunca foi sobre o custo de escrever a funcionalidade. Era sobre o custo de carregar ela até o dia em que ela faz sentido. Esse e o detalhe que mais se perde nas discussões.

Como adotar o YAGNI no dia a dia

Aplicar o YAGNI não exige ferramenta nenhuma, apenas uma mudança de hábito. Da para começar com passos concretos:

  • Passo 1: diante de uma funcionalidade nova, pergunte "existe uma demanda real e atual para isso?". Se a resposta for "talvez no futuro", e candidato a YAGNI.
  • Passo 2: resolva o problema que esta na sua frente hoje, com a solução mais simples que funciona.
  • Passo 3: mantenha o código limpo e bem testado, para que adicionar a funcionalidade depois seja barato.
  • Passo 4: quando a necessidade real surgir, ai sim implemente, já com contexto de verdade em vez de palpite.

O segredo e que YAGNI e KISS andam juntos. Quanto mais simples o seu código, mais barato fica voltar e mexer nele quando o futuro finalmente chegar.

Importante: YAGNI não significa abrir mao de testes, de boa arquitetura ou de código legível. Essas coisas reduzem o custo de mudança, e e justamente isso que torna o YAGNI viável.

Exemplo prático

Imagine que você esta construindo um cadastro de clientes para uma loja. A tarefa atual e simples: salvar nome, email e telefone. No meio do caminho, você pensa: "e se um dia precisarmos suportar vários endereços por cliente, com tags, histórico e exportação para três formatos diferentes?".

Sem YAGNI, você gasta dois dias criando uma estrutura de endereços múltipla, um sistema de tags e três exportadores. A loja, por enquanto, só queria guardar o telefone do cliente.

Com YAGNI, você entrega o cadastro simples que foi pedido, com testes e código limpo. Se daqui a três meses a loja realmente precisar de múltiplos endereços, você adiciona com base no que o negócio descobriu nesse tempo, e não no que você imaginou que ele ia querer.

Comparação com outras filosofias

O YAGNI costuma ser citado junto de outros princípios, e e útil entender onde cada um entra:

  • KISS (Keep It Simple, Stupid): prega manter as soluções simples. O YAGNI e quase uma aplicação do KISS no tempo: não adicione complexidade antes da hora.
  • DRY (Don't Repeat Yourself): evita duplicação de conhecimento no código. Cuidado: aplicar DRY cedo demais, generalizando algo que só apareceu uma vez, e justamente o tipo de previsão que o YAGNI crítica.
  • Design especulativo: e o oposto do YAGNI. Constrói abstrações e "ganchos" para necessidades futuras imaginadas. Funciona quando o futuro e muito previsível, o que é raro.

Na prática, o ponto forte do YAGNI e te lembrar de que adiar uma decisão costuma ser mais barato do que tomar a decisão errada cedo. Você troca uma aposta por mais informação.

Pontos positivos e limitações

O YAGNI tem benefícios claros. Ele reduz o tamanho do código, deixa o sistema mais fácil de entender, acelera entregas e evita que a equipe mantenha funcionalidades que ninguém usa. Tudo isso se traduz em menos custo de manutenção.

Mas ele tem limites e pode ser mal usado. Aplicado de forma extrema, vira desculpa para nunca pensar em arquitetura, ignorar requisitos óbvios ou pular testes e tratamento de erros. Isso não e YAGNI, e falta de cuidado.

Existem casos em que prever o futuro vale a pena, como decisões estruturais que são muito caras de mudar depois (a escolha de um banco de dados, um contrato de API público). Nesses pontos, o custo de errar tarde supera o custo de pensar cedo. YAGNI e um guia, não um dogma.

Casos de uso reais

O principio serve para perfis bem diferentes de quem escreve software:

  • Dev em startup: com prazo curto e produto ainda mudando, evitar código especulativo e questão de sobrevivência. O que parece essencial hoje pode ser jogado fora na próxima semana.
  • Time de produto consolidado: ajuda a frear o impulso de "já que estou aqui, vou deixar preparado para X", que infla o sistema sem demanda real.
  • Freelancer ou autónomo: entregar o escopo combinado de forma enxuta protege o prazo e o orçamento, sem regalar horas em funcionalidades que o cliente não pediu.
  • Estudante e iniciante: aprender YAGNI cedo evita o vicio de querer prever tudo e ajuda a focar em fazer funcionar primeiro.

Dicas e boas práticas

Quem aplica YAGNI ha tempo costuma seguir algumas práticas que evitam os exageros dos dois lados:

  • Distinga necessidade real de necessidade imaginada: "o cliente pediu" e diferente de "acho que vao pedir".
  • Invista no que reduz custo de mudança: testes, nomes claros e funções pequenas tornam barato voltar depois. Isso nunca e YAGNI.
  • Cuidado com a generalização precoce: espere o padrão aparecer ao menos duas ou três vezes antes de criar uma abstração.
  • Trate decisões irreversíveis com mais peso: para escolhas caras de desfazer, vale pensar no futuro com calma.

O erro mais comum de iniciantes e usar YAGNI como argumento para pular qualidade. O erro mais comum de seniores e o oposto: construir frameworks internos para problemas que nunca vao existir. O equilíbrio esta no meio.

Vale a pena adotar?

Vale, e bastante, desde que você entenda o que ele realmente diz. YAGNI e uma das ideias mais eficazes para manter sistemas enxutos e times rápidos, porque ataca um desperdício que quase todo mundo comete sem perceber.

Para quem esta começando, ele é um antídoto contra a ansiedade de prever tudo. Para quem já tem experiência, e um lembrete de que carregar código custa caro e que adiar uma decisão costuma ser a jogada mais inteligente.

O próximo passo e simples: na sua próxima tarefa, quando bater aquela vontade de "já deixar preparado para o futuro", pare e pergunte se você vai mesmo precisar disso agora. Na maioria das vezes, a resposta sincera vai ser não.