“Parece que vamos precisar disso depois. Quer deixar pronto agora?”
Durante o desenvolvimento, essa tentação aparece o tempo todo. Deixamos opções de configuração prontas, estruturamos o suporte a múltiplos idiomas e até criamos tabelas para permitir alterações pelo painel administrativo.
O YAGNI, tema de hoje, é o princípio que responde diretamente “não” a essa tentação. Ao lado de KISS e DRY, ele é considerado um dos três grandes princípios de desenvolvimento.
YAGNI é a sigla de “You Aren’t Gonna Need It”, que significa “você não vai precisar disso de qualquer forma”.
A expressão surgiu na metodologia de desenvolvimento Extreme Programming (XP). O que pessoas do grupo de XP, como Kent Beck e Ron Jeffries, usavam como bordão acabou se consolidando como um princípio.
A ideia central é uma só.
Implemente uma funcionalidade quando ela se tornar realmente necessária, não quando você prever que talvez precise dela.
Qual é o problema de fazer antes?
A objeção “se fizermos antes, depois fica mais fácil, não é?” certamente vai aparecer. O problema é que a maioria dessas previsões está errada.
Em um artigo sobre o tema, Martin Fowler divide o custo de funcionalidades criadas antecipadamente em quatro categorias.
| Custo | Conteúdo |
|---|---|
| Custo de implementação | O tempo gasto para criar uma funcionalidade que não será usada agora |
| Custo do atraso | A funcionalidade real que deveria ter sido criada nesse tempo acaba atrasada |
| Custo de manutenção | Mesmo o código não utilizado continua exigindo testes, refatoração e correções de bugs |
| Custo de reparo | Quando finalmente se torna necessário, o requisito mudou e é preciso refazer tudo |
O último é o que mais dói. Quando o “depois” finalmente chega, os requisitos quase sempre são diferentes do que imaginávamos. No fim, pagamos em dobro também pelo custo de refazer o código criado antecipadamente.
Situações em que o YAGNI é quebrado no dia a dia
Falando assim, todo mundo concorda, mas na prática ele entra sorrateiramente destas formas.
1. Deixar parâmetros prontos antecipadamente
// Agora só existem notificações por e-mail
func sendNotification(user: User, message: String, channel: String = "email",
retryCount: Int = 3, priority: String = "normal",
template: String? = nil) {
// channelque funciona somente quando "email"
}Todos os pontos de chamada usam apenas sendNotification(user: user, message: msg). Os demais parâmetros foram criados “para usar quando adicionássemos notificações do Slack”, mas essa demanda nunca apareceu.
2. Criar o protocolo antes da hora
É o caso de criar um protocolo mesmo quando existe apenas uma implementação. O padrão é criar um UserService junto com UserServiceProtocol, mas, até surgir uma segunda implementação, esse protocolo é apenas enfeite e aumenta a quantidade de arquivos.
3. “É melhor colocar na configuração, não é?”
Com medo de usar hardcode, colocamos todos os valores em arquivos de configuração e telas administrativas. Na prática, essas configurações nem são alteradas uma vez por ano; quanto mais elas aumentam, mais surgem perguntas como “o que é afetado se eu mudar este valor?”.
O que não é YAGNI
Para evitar mal-entendidos, vamos deixar os limites claros. YAGNI não significa o seguinte.
Primeiro, não significa que você não deve projetar. Esforços para tornar o código fácil de modificar (bons nomes, funções pequenas e testes) já têm valor imediato, portanto não são alvo do YAGNI. Pelo contrário: o código precisa ser fácil de alterar para que possamos criar rapidamente o necessário “quando chegar a hora”.
Também não significa adiar decisões difíceis de reverter. Escolhas como banco de dados ou a especificação pública de uma API devem ser avaliadas antecipadamente, pois são difíceis de mudar depois de definidas. O YAGNI mira “funcionalidades que poderiam ser adicionadas facilmente mais tarde, mas são criadas antes da hora”.
Meu critério para tomar decisões
Quando penso “será que deixo pronto antes?”, faço duas perguntas.
A evidência de que essa funcionalidade é necessária está no roadmap ou apenas na minha imaginação?
Se eu adicionar depois, ficará muito mais caro do que fazer agora?
Se a evidência está apenas na imaginação e o custo de adicionar depois é parecido, não faço. A maioria dos casos acaba se enquadrando aqui.
Resumo
Há três pontos para levar do princípio YAGNI.
- Crie funcionalidades quando elas se tornarem necessárias, não quando parecer que talvez sejam necessárias.
- Funcionalidades criadas antecipadamente cobram quatro vezes: implementação, atraso, manutenção e reparo.
- Mas bons hábitos de design e decisões difíceis de reverter não são alvo do YAGNI.
Quando colocamos KISS, DRY e YAGNI lado a lado, os três princípios acabam se resumindo a uma frase: crie o que é necessário hoje, de forma simples e em um único lugar.
Se houver pelo menos uma funcionalidade adormecida que você criou pensando “um dia vamos usar”, talvez daqui a 2 anos você precise apagá-la com as próprias mãos.