O que é o princípio YAGNI

YAGNI é a sigla de You Aren't Gonna Need It, que em português significa algo como "você não vai precisar disso". É uma das frases mais repetidas entre desenvolvedores experientes, e também uma das mais ignoradas na prática do dia a dia.

A ideia nasceu dentro do Extreme Programming (XP), a metodologia ágil popularizada por Kent Beck e Ron Jeffries no final dos anos 1990. O conselho central é simples: não escreva código para resolver uma necessidade que você apenas imagina que vai existir no futuro. Escreva apenas o que o problema atual exige.

O princípio voltou ao centro das discussões porque, com times cada vez menores e prazos mais curtos, cada hora gasta construindo algo que ninguém pediu é uma hora a menos para entregar o que realmente importa. YAGNI não é preguiça: é foco.

Como funciona o raciocínio por trás do YAGNI

A lógica do YAGNI parte de uma constatação incômoda: somos péssimos em prever o futuro de um software. Aquela funcionalidade "que com certeza vamos precisar" muitas vezes nunca chega, ou chega de um jeito completamente diferente do que você imaginou.

Quando você constrói algo por antecipação, paga vários custos de uma vez. Há o custo de construir a feature agora, o custo de carregar esse código extra (que precisa ser lido, testado e mantido mesmo sem ser usado) e o custo de consertar quando a suposição se mostra errada e tudo precisa ser refeito.

YAGNI propõe adiar a decisão até o momento em que você tem informação de verdade. Decidir mais tarde quase sempre significa decidir melhor, porque aí você conhece o problema real, e não a sua suposição sobre ele.

As ideias centrais que o YAGNI defende

O YAGNI não é uma regra isolada, e um conjunto de atitudes em relação a como você gasta seu tempo de desenvolvimento. Os pontos mais importantes são:

  • Resolva o problema de hoje: implemente exatamente o que a tarefa atual exige, nem mais, nem menos.
  • Evite abstração especulativa: não crie camadas, interfaces ou parâmetros de configuração para casos que ainda não existem.
  • Prefira mudar depois a adivinhar agora: código simples e fácil de mudar quando a necessidade real aparecer.
  • Menos código, menos bug: cada linha que você não escreve é uma linha que não pode quebrar.

Repare que nada disso diz para escrever código ruim ou sem cuidado. YAGNI anda de mãos dadas com bom design: o objetivo é um código simples e limpo o suficiente para ser fácil de evoluir quando a hora chegar.

É justamente essa combinação que separa o YAGNI de simplesmente "fazer o mínimo". A meta é clareza, não gambiarra.

Como começar a aplicar o YAGNI no seu código

Adotar o YAGNI é mais uma mudança de hábito do que de ferramenta. Da para começar hoje, em qualquer linguagem ou framework, seguindo alguns passos práticos.

Passo 1: antes de escrever qualquer abstração, pergunte "alguma tarefa atual realmente precisa disso?". Se a resposta for "talvez no futuro", pare.

Passo 2: escreva a solução mais direta que resolve o caso de uso atual. Sem opções configuráveis que ninguém pediu, sem suporte a cenários hipotéticos.

Passo 3: garanta bons testes para o que existe. Isso da a segurança de refatorar depois, quando a necessidade real surgir.

Passo 4: quando a nova exigência chegar de verdade, refatore com calma. Como o código atual é simples e testado, evoluir tende a ser mais barato do que você imagina.

Exemplo prático: o parâmetro que nunca foi usado

Imagine que você precisa de uma função para calcular o frete de um pedido. A regra atual é única: frete fixo por região. Um código guiado por YAGNI fica assim:

function calcularFrete(região) {
  const tabela = { sul: 15, sudeste: 12, norte: 25 };
  return tabela[região] ?? 30;
}

Agora veja a versão "preparada para o futuro", cheia de suposições que ninguém pediu: peso, dimensões, transportadora, cupom, prazo. Tudo isso sem nenhuma regra de negócio real exigindo:

function calcularFrete(região, peso, dimensões, transportadora, cupom, prazo, opcoes) {
  // dezenas de linhas tratando casos que ainda não existem
}

A segunda versão parece mais robusta, mas é uma armadilha. Ninguém usa esses parâmetros, eles precisam ser testados e mantidos, e quando a regra real de peso finalmente chegar, ela provavelmente será diferente do que você chutou. YAGNI manda começar pela primeira versão e evoluir só quando o negócio pedir.

YAGNI, KISS, DRY e o Big Design Up Front

O YAGNI faz parte de uma família de princípios que valorizam a simplicidade. Vale entender como ele se relaciona com os vizinhos mais conhecidos.

KISS (Keep It Simple, Stupid) prega manter a solução simples; o YAGNI é mais específico e diz quando não construir algo: quando ainda não há necessidade. DRY (Don't Repeat Yourself) combate duplicação, mas pode entrar em tensão com o YAGNI quando você cria uma abstração cedo demais só para evitar repetir código que talvez nunca se repita.

Do lado oposto está o Big Design Up Front, a ideia de desenhar todo o sistema em detalhes antes de escrever a primeira linha. O YAGNI é a resposta ágil a esse modelo: projete o suficiente para começar, aprenda com o código rodando e ajuste o rumo com base em fatos.

Pontos positivos e limitações

Como todo princípio, o YAGNI tem força e também armadilhas. Aplica-lo no automático, sem pensar, pode ser tao prejudicial quanto ignora-lo.

Entre os pontos positivos: menos código morto, entregas mais rápidas, base de código mais fácil de entender e menos tempo perdido com features que ninguém usa. Times que respeitam o YAGNI costumam ter menos dívida técnica acumulada por especulação.

Entre as limitações: existem decisões que são caras de mudar depois, como escolha de banco de dados, contratos de API pública ou pontos de segurança. Nesses casos, um mínimo de planejamento antecipado é saudável. YAGNI vale mais para detalhes internos e features de negócio do que para decisões estruturais difíceis de reverter.

Casos de uso reais: para quem o YAGNI faz diferença

O princípio ajuda perfis bem diferentes de quem escreve software. Alguns exemplos concretos:

O desenvolvedor de startup: precisa validar uma ideia rápido, com poucos recursos. Construir só o necessário para o MVP funcionar é a diferença entre lançar e ficar preso em código que ninguém vai usar.

O dev que mantem sistema legado: ao mexer em código antigo, resistir a adicionar "melhorias preventivas" evita introduzir novos riscos em algo que já é frágil.

O time de produto: ao priorizar o backlog, o YAGNI vira aliado para cortar funcionalidades especulativas e focar no que gera valor medido por uso real, e não por achismo.

O iniciante: aprender a não se perder em abstrações prematuras acelera muito a curva de aprendizado e ajuda a entregar código funcionando mais cedo.

Dicas e boas práticas para aplicar sem exagerar

O segredo do YAGNI é o equilíbrio. Desenvolvedores experientes seguem alguns padrões para não cair no extremo de nunca planejar nada.

  • Diferencie "fácil de mudar" de "caro de mudar": seja agressivo com o YAGNI no que é barato reverter e mais cauteloso no que é estrutural.
  • Use testes como rede de segurança: eles dao confiança para começar simples e refatorar quando a necessidade real chegar.
  • Documente decisões adiadas: registre que você escolheu não tratar um caso ainda, para o time saber que foi proposital, e não esquecimento.
  • Cuidado com o YAGNI usado como desculpa: ele não justifica pular tratamento de erro, segurança ou acessibilidade que já são necessários hoje.

O erro mais comum de iniciantes é confundir YAGNI com escrever menos do que o problema atual exige. O princípio fala de necessidades futuras imaginárias, não das reais e presentes.

Vale a pena adotar o YAGNI?

Para a grande maioria dos projetos, sim. O YAGNI é um dos conselhos com melhor relação entre esforço e retorno: não custa nada adotar e economiza horas de trabalho desperdiçado em código que ninguém pede.

Ele faz mais sentido ainda em times pequenos, startups e produtos em evolução rápida, onde cada hora conta e os requisitos mudam o tempo todo. Em sistemas com decisões estruturais de alto custo, use com bom senso e combine com um mínimo de planejamento.

O próximo passo é simples: na sua próxima tarefa, antes de criar aquela abstração "para o futuro", pergunte se alguma necessidade real de hoje justifica. Se a resposta for não, você acabou de aplicar YAGNI, e seu código vai agradecer.