 |
| Bellacosa Mainframe e a yagni rules |
☕ Um Café no Bellacosa Mainframe
YAGNI Rules sem Mistérios
Quando um Programador COBOL Descobriu que a Matrix Estava Cheia de Recursos Que Ninguém Jamais Usaria
"O código mais caro não é aquele que foi escrito. É aquele que foi escrito para um futuro que nunca chegou."
Prólogo — O Depósito das Funcionalidades Fantasma
Após derrotar mais uma legião de Agentes Smith, Neo recebeu um convite inesperado do Arquiteto.
— Hoje vou lhe mostrar um lugar que nem mesmo o Oráculo costuma visitar.
Os dois atravessaram uma enorme porta metálica escondida atrás do núcleo da Matrix.
Do outro lado havia um gigantesco depósito.
Prateleiras infinitas.
Milhões de linhas de código.
Módulos completos.
APIs.
Menus.
Botões.
Rotinas.
Neo perguntou:
— O que é tudo isso?
O Arquiteto respondeu:
— Funcionalidades.
Neo ficou impressionado.
— Quantas pessoas usam?
Silêncio.
Depois de alguns segundos o Arquiteto respondeu:
— Nenhuma.
Neo caminhou entre corredores intermináveis.
Encontrou módulos chamados:
FUTURO-PROJETO.
CLIENTE-PREMIUM-V3.
IA-EXPERIMENTAL.
RELATORIO-UNIVERSAL.
MODULO-MULTIMOEDA.
SISTEMA-DE-TELETRANSPORTE.
Perguntou:
— Isso tudo está em produção?
O Arquiteto respondeu.
— Está.
— Funciona?
— Sim.
— É usado?
— Nunca foi.
O Oráculo apareceu.
Serviu café para Neo.
Depois disse calmamente:
"O maior desperdício da engenharia não é escrever código ruim. É escrever código que jamais resolverá um problema real."
Naquele momento Neo compreendeu o verdadeiro significado do YAGNI.
O que significa YAGNI?
YAGNI significa:
You Aren't Gonna Need It
Em português:
"Você não vai precisar disso."
É um dos princípios mais conhecidos da metodologia Extreme Programming (XP).
Sua ideia é extremamente simples.
Não implemente hoje funcionalidades que talvez sejam necessárias amanhã.
Implemente apenas aquilo que resolve um problema existente.
A origem do princípio
O YAGNI surgiu no final da década de 1990 dentro do movimento Extreme Programming, criado por Kent Beck.
Na época, muitas equipes gastavam enorme quantidade de tempo construindo recursos para um futuro hipotético.
Esses recursos quase nunca eram utilizados.
Kent Beck propôs uma filosofia radical.
Construa somente aquilo que possui necessidade comprovada.
Quando surgir uma nova necessidade.
Implemente naquele momento.
Matrix explica perfeitamente
Imagine que o Arquiteto resolvesse prever todas as possibilidades da humanidade.
Então incluiria:
controle de dragões;
módulo para dinossauros;
protocolo para viagens no tempo;
economia marciana;
integração com civilizações alienígenas.
Tudo isso "caso um dia seja necessário".
Resultado?
A Matrix seria gigantesca.
Difícil de manter.
Lenta.
Cheia de código inútil.
Como nasce o excesso?
Sempre começa com boas intenções.
Alguém diz.
"Vai que um dia..."
Depois aparecem frases como:
"Já vamos deixar preparado."
"Aproveita e cria também..."
"É só mais um IF."
"No futuro pode servir."
Meses depois.
Ninguém usa.
O COBOL conhece isso muito bem
Imagine um sistema bancário.
O requisito diz:
Calcular IOF.
O desenvolvedor pensa.
"Vai que um dia o banco trabalhe com Bitcoin, Ouro, Marte e Lua."
Então cria:
vinte tabelas;
quinze tipos de moeda;
cinquenta parâmetros.
Quando entra em produção.
Existe apenas:
Real.
Um exemplo COBOL
Requisito.
Calcular juros.
Solução simples.
COMPUTE JUROS = SALDO * TAXA
Solução YAGNI ignorado.
Cria:
Framework de cálculo.
Plugin.
Factory.
Reflection.
Configuração XML.
API REST.
Tabela dinâmica.
Tudo para multiplicar dois números.
Matrix Reloaded
O Arquiteto mostra milhares de possibilidades futuras.
Neo pergunta.
— Precisamos construir tudo isso?
O Arquiteto responde.
— Não.
O Oráculo sorri.
— O futuro ainda não decidiu existir.
O efeito psicológico
Existe um medo comum entre desenvolvedores.
"E se amanhã precisarmos?"
Essa pergunta gera enormes desperdícios.
Porque o amanhã raramente acontece exatamente como imaginamos.
O Programador COBOL Padawan
Imagine seu primeiro projeto.
O gerente pede:
— Precisamos gerar um relatório.
Você responde.
— Já vou criar vinte modelos diferentes.
Pergunta.
O cliente pediu vinte?
Não.
Pediu um.
O Agente Smith ama funcionalidades imaginárias
Porque cada funcionalidade extra gera:
novos bugs;
novos testes;
nova documentação;
novas dependências;
novas exceções.
Quanto mais código.
Maior a superfície para ataques.
Um exemplo inspirado na Matrix
Neo pergunta.
— Quantas portas existem?
O Chaveiro responde.
— Mil.
Neo pergunta.
— Quantas usamos?
— Dez.
As outras novecentas e noventa foram criadas "caso um dia fossem necessárias".
O custo invisível
Toda funcionalidade possui custo.
Mesmo sem uso.
Ela precisa:
compilar;
ser testada;
documentada;
protegida;
revisada;
mantida.
Nada é gratuito.
O impacto no Mainframe
Em ambientes IBM Z aparecem frequentemente:
COPYBOOKs preparados para campos inexistentes;
layouts gigantes;
tabelas nunca utilizadas;
JCLs reservados para processos imaginários;
programas chamados apenas "no futuro".
Tudo isso aumenta:
CPU;
armazenamento;
manutenção.
Curiosidade
Diversos estudos em desenvolvimento de software mostram que uma parcela significativa das funcionalidades presentes em sistemas corporativos é usada muito raramente ou nunca é utilizada pelos usuários finais.
Isso reforça a importância de validar necessidades reais antes de implementar novas capacidades.
Atenção!
YAGNI não significa:
"Nunca pensar no futuro."
Significa:
"Não implementar antes da hora."
Arquitetura pode prever evolução.
Código desnecessário não.
A diferença
Preparar arquitetura
Permitir crescimento.
Implementar tudo
Criar desperdício.
Matrix e Zion
Imagine construir:
cem hangares;
mil naves;
cinquenta hospitais.
Antes mesmo de saber quantas pessoas viverão em Zion.
Seria desperdício.
Ferramentas ajudam
Hoje podemos medir uso real.
Telemetria.
Analytics.
Logs.
Feature Flags.
IBM Instana.
OMEGAMON.
Monitoramento de APIs.
Esses dados mostram o que realmente é utilizado.
O papel da IA
A IA frequentemente sugere funcionalidades extras.
Cabe ao engenheiro perguntar.
"O cliente pediu isso?"
Se a resposta for não.
Talvez seja YAGNI.
Os riscos
Ignorar YAGNI gera:
overengineering;
manutenção cara;
código morto;
testes maiores;
documentação enorme;
mais bugs.
Erros clássicos
Programar para cenários imaginários.
Criar abstrações prematuras.
Implementar requisitos inexistentes.
Confundir arquitetura extensível com funcionalidades prontas.
Aceitar "vai que um dia".
Boas práticas
Desenvolver apenas requisitos atuais.
Validar com usuários.
Medir utilização.
Evoluir incrementalmente.
Refatorar quando necessário.
Simplificar continuamente.
Aplicabilidade
YAGNI aparece em:
COBOL.
Java.
Python.
Cloud.
APIs.
Microsserviços.
Mobile.
IA.
DevOps.
ERP.
Um exemplo COBOL
Cliente pede.
Cadastro de Endereço.
Você cria.
Rua.
Número.
Cidade.
Estado.
CEP.
Não precisa adicionar:
Colônia em Marte.
Quadrante Galáctico.
Planeta de Origem.
Coordenadas Quânticas.
Até que alguém realmente peça.
YAGNI e os outros princípios
YAGNI conversa diretamente com quase todos os princípios estudados nesta série.
Ele reduz:
Golden Hammer, porque evita criar soluções grandiosas para problemas pequenos.
Lasagna Code, porque impede camadas desnecessárias.
Lava Flow, porque evita código que nunca será usado e depois ninguém tem coragem de remover.
Boiling Frog, porque impede o crescimento silencioso da complexidade.
KISS, porque incentiva soluções simples.
Death March, porque reduz trabalho desnecessário.
Brooks's Law, porque menos funcionalidades significam menos necessidade de crescimento artificial da equipe.
YAGNI é um excelente antídoto contra o excesso de zelo que acaba produzindo desperdício.
O ensinamento do Oráculo
O Oráculo entrega uma mochila para Neo.
Dentro dela existem:
vinte lanternas;
quinze bússolas;
dez rádios;
cinco espadas;
três computadores;
duas cafeteiras.
Neo tenta levantá-la.
Não consegue.
Ela retira tudo.
Deixa apenas:
uma bússola.
água.
e uma lanterna.
Neo sorri.
— Agora consigo caminhar.
Ela responde.
"Quem leva tudo para uma jornada acaba sem forças para percorrê-la."
Lições para um Programador COBOL Padawan
Ao longo da carreira você ouvirá muitas sugestões começando com:
"Já aproveita..."
"Vai que..."
"Quem sabe no futuro..."
"Deixa preparado..."
Antes de aceitar, faça algumas perguntas:
Existe um requisito aprovado?
Há uma necessidade real?
Algum usuário pediu isso?
Existe previsão concreta de uso?
Estamos aumentando a complexidade sem necessidade?
Se a resposta for "não", provavelmente você está diante de um caso clássico de YAGNI.
Projetar sistemas preparados para evoluir é excelente.
Implementar funcionalidades imaginárias é desperdício.
Curiosidades
O princípio YAGNI influenciou fortemente várias práticas modernas:
Agile, priorizando valor entregue a cada iteração.
Lean Software Development, eliminando desperdícios.
Feature Flags, permitindo ativar funcionalidades apenas quando realmente necessárias.
MVP (Minimum Viable Product), que incentiva lançar a menor solução capaz de gerar valor.
Continuous Delivery, favorecendo evolução contínua em vez de grandes antecipações.
Todos compartilham a mesma ideia: desenvolva apenas aquilo que gera valor agora.
Conclusão — O Futuro Ainda Não Escreveu Seu Código
Quando Neo percorreu o depósito do Arquiteto, percebeu que milhares de módulos existiam apenas para responder a perguntas que ninguém jamais faria.
Na Engenharia de Software isso acontece com frequência.
O princípio YAGNI nos lembra que o futuro é imprevisível. As funcionalidades imaginadas hoje dificilmente corresponderão exatamente às necessidades reais de amanhã.
Para um Programador COBOL, especialmente em ambientes IBM Z onde estabilidade, desempenho e facilidade de manutenção são essenciais, escrever menos código costuma ser uma decisão mais inteligente do que escrever código "por precaução".
Cada linha adicionada representa mais testes, mais documentação, mais manutenção e mais oportunidades para o Agente Smith encontrar uma brecha.
No universo Bellacosa Mainframe existe uma máxima que certamente estaria gravada na oficina do Chaveiro:
"Não construa hoje a chave de uma porta que talvez nunca exista. Quando essa porta aparecer, você terá conhecimento, ferramentas e experiência para fabricar exatamente a chave de que ela precisa."
Porque o verdadeiro engenheiro não é aquele que tenta prever todos os futuros possíveis.
É aquele que constrói sistemas simples, elegantes e preparados para evoluir quando o futuro finalmente bater à porta.
