YAGNI: Como o Princípio Evita que Você Sabote o Próprio Código
O princípio YAGNI pode transformar a forma como você escreve código. Se você já perdeu dias desenvolvendo funcionalidades que nunca foram usadas, este artigo é para você. Nele, você vai entender o que é o YAGNI, de onde ele vem e como aplicá-lo no dia a dia do desenvolvimento.
O que é o Princípio YAGNI?
YAGNI é a sigla para You Aren’t Gonna Need It, ou seja, “Você Não Vai Precisar Disso”. Trata-se de um dos princípios mais importantes da engenharia de software moderna. Sua mensagem é simples: não implemente nada que não seja necessário agora.
Não amanhã. Não “por garantia”. Não “porque pode ser útil um dia”. Apenas o que o sistema precisa hoje.
O princípio surgiu dentro do Extreme Programming (XP), formulado por Kent Beck no final dos anos 1990. O XP propunha uma mudança radical no desenvolvimento de software. Em vez de planejar tudo antecipadamente, a ideia era trabalhar em ciclos curtos e adaptar o sistema conforme a realidade do projeto se revelava.
Dentro desse contexto, o YAGNI surgiu como resposta a um problema concreto: o custo invisível do código especulativo. Código especulativo é todo trecho escrito não porque o sistema precisa agora, mas porque você acha que será necessário no futuro.
Kent Beck resumiu o princípio de forma clara:
“Implemente as coisas quando você realmente precisar delas, nunca quando você apenas prever que vai precisar.”
O princípio YAGNI não é um convite à irresponsabilidade. Ele não diz para ignorar o futuro. Ele diz para não construir o futuro antes que ele chegue.
Por que o Código Especulativo Tem um Custo Alto?
Muitos desenvolvedores tratam código como algo gratuito. Afinal, escrever mais linhas não gera uma fatura no final do mês. Essa percepção, porém, é enganosa. Todo código tem custo, e ele se manifesta em quatro dimensões.
Tempo de desenvolvimento desperdiçado
Cada funcionalidade implementada antes da hora é tempo que poderia ir para o que realmente importa. Se você gasta dois dias construindo um sistema de cache sofisticado para um aplicativo com dez usuários, você perdeu dois dias. Esse tempo poderia ter ido para corrigir bugs reais ou lançar uma funcionalidade solicitada pelos clientes.
Complexidade desnecessária no código
Todo trecho adicionado torna o sistema um pouco mais difícil de entender. Abstrações desnecessárias criam camadas que outros desenvolvedores precisarão decifrar. Um sistema simples com três classes pode ser compreendido em minutos. O mesmo sistema com doze classes e cinco interfaces desnecessárias exige horas de estudo.
Custo de manutenção oculto
Código que existe precisa ser mantido. Ele precisa ser testado, atualizado quando as dependências mudam e corrigido quando apresenta bugs. Código que ninguém usa também tem bugs — e eles ficam escondidos até o pior momento possível.
Custo de oportunidade
Cada hora gasta em código especulativo é uma hora não investida em algo que gera valor real. Em um mercado onde a velocidade de entrega pode determinar o sucesso de um produto, esse custo é alto demais para ser ignorado.
Como Aplicar o Princípio YAGNI na Prática
Entender o conceito é o primeiro passo. O verdadeiro desafio está em aplicá-lo nas decisões cotidianas. Veja três cenários concretos.
Cenário 1: O banco de dados “preparado para tudo”
Imagine que você está criando um e-commerce pequeno. O requisito atual é vender produtos físicos. Mesmo assim, você pensa: “E se no futuro a gente vender produtos digitais? Melhor criar tabelas separadas e uma estrutura de herança no banco.”
Aplicando o princípio YAGNI, a decisão é diferente. Você cria a tabela de produtos com os campos necessários agora: nome, descrição, preço, estoque e imagens. Se a necessidade de produtos digitais surgir no futuro, você adiciona os campos naquele momento — com requisitos reais, não suposições.
Cenário 2: A abstração prematura
Você precisa enviar e-mails de confirmação e usa o SendGrid. Contudo, você pensa: “E se trocarmos de provedor? Melhor criar uma interface genérica e um adapter pattern.”
Com o YAGNI, você implementa o envio diretamente com o SendGrid, de forma limpa e organizada. Se a troca de provedor se tornar necessária, você refatora naquele momento. Com bons testes, essa mudança costuma ser muito mais simples do que parece.
Cenário 3: Funcionalidades “que seriam legais”
Em uma reunião, alguém sugere: “Seria legal se o usuário pudesse exportar relatórios em PDF, Excel e CSV.” No entanto, o único pedido concreto dos clientes até agora é a visualização dos dados na tela.
O princípio YAGNI recomenda implementar a visualização na tela com qualidade. Se, depois do lançamento, os clientes pedirem exportação, você implementa o formato mais solicitado — não os três de uma vez.
A pergunta-filtro essencial
Para cada funcionalidade que você está prestes a implementar, faça a si mesmo uma pergunta simples:
“Existe alguém pedindo isso agora, ou estou antecipando uma necessidade que pode nunca se concretizar?”
Se a resposta for a segunda opção, pare. Anote a ideia em um backlog e siga com o que é necessário hoje.
YAGNI, KISS e DRY: Como Esses Princípios se Relacionam
O princípio YAGNI não existe isolado. Ele faz parte de uma família de princípios que, juntos, formam a base de um desenvolvimento saudável.
O KISS (Keep It Simple, Stupid) prega que a solução mais simples é quase sempre a melhor. Enquanto o YAGNI foca em o que construir, o KISS foca em como construir. Os dois se complementam: o YAGNI impede que você construa coisas desnecessárias; o KISS garante que o necessário seja feito sem complexidade artificial.
O DRY (Don’t Repeat Yourself) diz que cada pedaço de conhecimento deve ter uma única representação no sistema. Aqui, porém, existe uma tensão importante: aplicar o DRY prematuramente pode violar o YAGNI. Forçar uma abstração para unificar dois trechos de código que atendem a contextos diferentes pode gerar uma abstração frágil.
A orientação prática é conhecida como Regra de Três: se um padrão se repete duas vezes, observe. Se se repete três vezes em contextos genuinamente similares, considere criar uma abstração. Duas ocorrências podem ser coincidência; três geralmente indicam um padrão real.
Quando Pensar no Futuro É Necessário
O princípio YAGNI não é uma regra absoluta. Existem situações em que considerar o futuro é responsabilidade, não especulação. Saber distinguir esses casos é fundamental.
Decisões difíceis de reverter exigem mais reflexão. Escolher o banco de dados principal, definir o protocolo entre microsserviços ou decidir a linguagem do projeto são decisões com alto custo de reversão. Nesses casos, é prudente pensar em cenários futuros. O YAGNI se aplica com mais força a decisões facilmente reversíveis.
Segurança e conformidade não são opcionais. Se o sistema lida com dados pessoais, implementar criptografia e controle de acesso desde o início não é código especulativo — é requisito legal.
Escalabilidade básica merece atenção. Você não precisa construir uma arquitetura para dez milhões de usuários quando tem cem. Por outro lado, tomar decisões que inviabilizem completamente o crescimento futuro é imprudência, não simplicidade.
Em resumo, o princípio YAGNI combate a implementação prematura de funcionalidades e abstrações, não o planejamento consciente de decisões estruturais.
Erros Comuns ao Ignorar o Princípio YAGNI
Mesmo desenvolvedores experientes cometem erros quando ignoram esse princípio. Veja os mais comuns.
Confundir preparação com adivinhação
A diferença é sutil, mas fundamental. Preparação significa garantir que o código seja limpo, bem testado e fácil de modificar. Adivinhação significa decidir hoje que o sistema precisará de suporte a múltiplas moedas e cinco integrações antes de ter um único cliente pagante. Código bem escrito já é código preparado para o futuro.
Usar o YAGNI como desculpa para código desleixado
Esse é o extremo oposto e é igualmente perigoso. Alguns desenvolvedores interpretam o YAGNI como autorização para escrever código sem testes e sem organização. Porém, o YAGNI não diz para fazer mal feito. Ele diz para fazer apenas o necessário, e fazer bem feito.
Resistir à refatoração quando a necessidade real aparece
O princípio YAGNI funciona em conjunto com a refatoração contínua. Quando uma necessidade real surgir, você modifica o código existente para acomodá-la. Contudo, se a equipe tem medo de mexer no código — geralmente por falta de testes automatizados —, a tendência é voltar a escrever código especulativo. Isso cria um ciclo vicioso: código especulativo gera complexidade, que gera medo de mudança, que gera mais código especulativo. A solução é investir em testes automatizados.
Aplicar o YAGNI a decisões de equipe e processo
O princípio YAGNI é uma ferramenta de design de software, não de gestão. Decidir não documentar o sistema porque “ninguém pediu” não é YAGNI — é negligência. Da mesma forma, não criar um pipeline de deploy automatizado porque “dá pra fazer manual por enquanto” é dívida técnica, não simplicidade.
Conclusão: O Princípio YAGNI como Hábito de Desenvolvimento
O princípio YAGNI é, na sua essência, um exercício de disciplina e honestidade intelectual. Ele pede que você resista à tentação de construir para um futuro imaginado e concentre sua energia no que é real e necessário agora.
Na prática, seguir o YAGNI resulta em sistemas mais simples, equipes mais produtivas, entregas mais rápidas e, paradoxalmente, código mais adaptável. Quando cada parte do sistema existe por uma razão concreta, qualquer mudança futura encontra menos obstáculos.
O próximo passo é direto: no seu próximo projeto, aplique a pergunta-filtro. Pergunte a si mesmo se o que você está prestes a escrever atende a uma necessidade real ou a uma suposição confortável. Com o tempo, essa pergunta deixa de ser um exercício consciente e se torna parte da sua forma de pensar código.ores 🚀.
Clique aqui e conheça nossos cursos na área de tecnologia da informação.