 |
| Bellacosa Mainframe e a dry rules |
☕ Um Café no Bellacosa Mainframe
DRY Rules sem Mistérios
Quando um Programador COBOL Descobriu que Existiam Mil Agentes Smith Porque Alguém Copiou o Mesmo Código Pela Matrix Inteira
"Duplicar código parece economizar alguns minutos hoje. Mas pode custar centenas de horas durante a vida inteira de um sistema."
Prólogo — A Invasão dos Mil Smiths
Neo corria pelos corredores da Matrix.
De repente.
Encontrou um Agente Smith.
Depois outro.
Depois dez.
Depois cem.
Depois milhares.
Todos eram idênticos.
Todos repetiam exatamente as mesmas frases.
Os mesmos movimentos.
Os mesmos ataques.
Neo perguntou ao Oráculo:
— Como isso aconteceu?
Ela respondeu serenamente:
— Alguém resolveu copiar em vez de reutilizar.
Neo ficou confuso.
— O que isso tem a ver com programação?
O Oráculo apontou para o código-fonte da Matrix.
Cada módulo possuía a mesma lógica repetida dezenas de vezes.
Mudava apenas um pequeno detalhe.
O Arquiteto apareceu.
Suspirou profundamente.
— Agora precisamos corrigir um bug.
Neo perguntou:
— Quantos lugares teremos que alterar?
O Arquiteto respondeu:
— Ainda estamos contando...
Naquele instante Neo compreendeu que o verdadeiro inimigo não era Smith.
Era a duplicação.
O que significa DRY?
DRY significa:
Don't Repeat Yourself
Em português:
"Não se repita."
É um dos princípios mais importantes da Engenharia de Software.
Sua ideia é simples.
Cada conhecimento deve existir em apenas um lugar.
Quando uma regra aparece repetida em vários pontos do sistema, surge um risco enorme.
Se a regra mudar.
Será necessário alterar todos os lugares.
Se esquecer apenas um.
O sistema ficará inconsistente.
A origem do DRY
O princípio foi apresentado em 1999 por Andy Hunt e Dave Thomas, no livro clássico:
The Pragmatic Programmer
Os autores definiram o DRY de forma elegante:
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
Ou seja.
Cada informação importante deve possuir uma única fonte oficial.
Matrix explica perfeitamente
Imagine que existam cinquenta versões diferentes da regra que controla a gravidade da Matrix.
Uma delas diz:
Gravidade = 9,8
Outra.
Gravidade = 9,7
Outra.
Gravidade = 10
O resultado?
Cada região da Matrix funciona de maneira diferente.
O COBOL conhece muito bem o DRY
Imagine uma regra tributária.
Ela aparece em:
Cadastro.
Cobrança.
Empréstimos.
Cartões.
PIX.
Internet Banking.
Tudo copiado.
Chega uma nova legislação.
Agora será preciso alterar:
seis programas.
Se esquecer apenas um.
Problema.
Um exemplo COBOL
Primeiro programa.
IF SALDO < 0
MOVE "N" TO APROVADO
END-IF
Segundo programa.
A mesma regra.
Terceiro.
Novamente.
Décimo.
Também.
Agora imagine.
A regra muda.
Saldo igual a zero também deve ser negado.
Quantos programas precisam mudar?
O COPYBOOK nasceu justamente para isso
Um dos maiores exemplos de DRY no COBOL.
Em vez de repetir estruturas.
Criamos:
COPY CLIENTE.
Agora.
Se o layout mudar.
Mudamos apenas um lugar.
Matrix Reloaded
Smith tornou-se perigoso justamente porque começou a se copiar infinitamente.
O mesmo acontece com regras de negócio.
Quanto mais cópias.
Mais difícil controlar.
O efeito psicológico
Existe uma tentação enorme.
"Vou copiar rapidinho."
Leva:
dez segundos.
Depois.
O sistema vive vinte anos.
O Programador COBOL Padawan
Você escreve:
CALCULA-JUROS.
Depois precisa da mesma lógica.
Em vez de criar uma rotina reutilizável.
Faz:
CTRL+C.
CTRL+V.
Parece eficiente.
Até a primeira manutenção.
O Agente Smith ama CTRL+C CTRL+V
Porque cada cópia.
É um novo esconderijo para bugs.
Um erro copiado.
É um erro multiplicado.
Um exemplo inspirado na Matrix
Imagine.
Existem cinquenta mapas de Zion.
Cada mapa possui uma pequena diferença.
Qual deles é verdadeiro?
Ninguém sabe.
O custo invisível
Duplicação gera:
manutenção maior;
testes maiores;
documentação maior;
bugs inconsistentes;
dificuldade de evolução.
O impacto no Mainframe
Grandes ambientes IBM Z frequentemente apresentam:
COPYBOOKs duplicados;
layouts semelhantes;
SQL repetido;
JCLs quase idênticos;
validações copiadas.
Quanto maior a duplicação.
Maior o esforço de manutenção.
Curiosidade
DRY não trata apenas de código.
Também vale para:
documentação;
configurações;
tabelas;
scripts;
APIs;
processos.
Conhecimento duplicado também é duplicação.
Atenção!
DRY não significa:
Transformar tudo em reutilização.
Existe outro princípio importante.
AHA
Avoid Hasty Abstractions.
Evite abstrações prematuras.
Primeiro compreenda o padrão.
Depois reutilize.
A diferença
Reutilização saudável
Uma regra.
Um local.
Reutilização exagerada
Tudo depende de um único módulo gigantesco.
Matrix e o Chaveiro
O Chaveiro fabrica uma chave para cada tipo de porta.
Mas não fabrica cem cópias da mesma chave escondidas pela Matrix.
Existe uma fonte.
Uma responsabilidade.
Ferramentas ajudam
Hoje temos:
SonarQube.
IBM ADDI.
Enterprise Analyzer.
Clone Detection.
Code Review.
IA.
Todas ajudam a localizar duplicações.
O papel da IA
A IA consegue detectar:
código semelhante;
SQL repetido;
COPYBOOKs equivalentes;
regras duplicadas.
Mas cabe ao arquiteto decidir como consolidar.
Os riscos
Ignorar DRY gera.
inconsistências.
bugs.
retrabalho.
dívida técnica.
manutenção cara.
baixa produtividade.
Erros clássicos
Copiar programas inteiros.
Duplicar SQL.
Repetir validações.
Criar layouts quase iguais.
Duplicar documentação.
Boas práticas
Modularizar.
Criar COPYBOOKs.
Utilizar subprogramas.
Centralizar regras.
Automatizar validações.
Revisar duplicações periodicamente.
Aplicabilidade
DRY aparece em:
COBOL.
Java.
Python.
C#.
APIs.
Cloud.
DevOps.
Scripts.
SQL.
Infraestrutura como Código.
DRY e o universo IBM Z
O ecossistema IBM Z oferece diversos mecanismos que incorporam naturalmente o espírito do DRY.
Entre eles:
COPYBOOKs, para compartilhar layouts de dados entre programas.
Subprogramas COBOL, evitando repetir regras de negócio.
Stored Procedures Db2, centralizando lógica próxima aos dados quando apropriado.
PROCs JCL, reutilizando definições de execução.
Macros HLASM, eliminando repetições em código Assembly.
Serviços CICS compartilhados, reutilizados por diferentes transações.
APIs corporativas, permitindo que uma única implementação atenda vários consumidores.
Todos esses recursos existem para evitar que o mesmo conhecimento seja implementado repetidamente.
Quando DRY pode ser exagerado?
Assim como qualquer princípio, o DRY pode ser levado ao extremo.
Imagine duas regras de negócio parecidas, mas que pertencem a domínios diferentes.
Forçá-las a usar a mesma rotina apenas porque "são semelhantes" pode criar um forte acoplamento.
Meses depois, uma regra muda.
A outra não.
Agora a reutilização passa a atrapalhar.
Por isso muitos arquitetos repetem uma frase importante:
"Não reutilize por preguiça de escrever código. Reutilize porque existe realmente um conhecimento comum."
DRY conversa com toda esta série
Ao longo dos artigos Bellacosa Mainframe, você já encontrou diversos princípios que se relacionam diretamente com o DRY.
Ele ajuda a evitar:
Spaghetti Code, reduzindo trechos repetidos espalhados pelo sistema.
Golden Hammer, porque incentiva pensar antes de copiar soluções.
Lava Flow, evitando múltiplas versões abandonadas da mesma regra.
Big Ball of Mud, diminuindo a desorganização.
KISS, favorecendo soluções claras e centralizadas.
YAGNI, impedindo a criação de módulos duplicados "para o futuro".
Perceba que todos esses princípios caminham na mesma direção:
software simples, consistente e sustentável.
O ensinamento do Oráculo
O Oráculo entrega a Neo um enorme livro.
Cada capítulo conta exatamente a mesma história.
Neo pergunta:
— Por que repetir tudo isso?
Ela sorri.
Depois entrega outro livro.
Nele existe apenas uma história.
Todos os capítulos fazem referência a ela.
Neo entende imediatamente.
Ela então diz:
"A verdade precisa existir apenas uma vez. Todas as cópias são oportunidades para que ela deixe de ser verdade."
Lições para um Programador COBOL Padawan
Durante sua jornada no universo IBM Z, você encontrará muitas oportunidades de usar o famoso CTRL+C / CTRL+V.
À primeira vista parece uma solução rápida.
Mas faça uma pausa.
Pergunte a si mesmo:
Essa regra já existe em outro lugar?
Posso transformá-la em um subprograma?
Um COPYBOOK resolveria?
Essa validação deveria ser centralizada?
Estou duplicando conhecimento ou apenas reutilizando uma estrutura?
Essas perguntas fazem enorme diferença ao longo dos anos.
Lembre-se de que a maior parte do custo de um software está na manutenção.
Quanto menos lugares precisarem ser alterados para implementar uma mudança de negócio, maior será a qualidade do sistema.
Curiosidades
O princípio DRY influenciou profundamente diversas tecnologias modernas:
Domain-Driven Design, incentivando uma única fonte para conceitos do domínio.
APIs REST e GraphQL, centralizando serviços reutilizáveis.
Infrastructure as Code, eliminando configurações duplicadas.
GitHub Actions, reutilizando pipelines.
Ansible, através de roles e playbooks compartilhados.
Kubernetes, reutilizando manifestos e templates.
CI/CD, automatizando tarefas repetitivas em vez de executá-las manualmente.
A ideia permanece exatamente a mesma apresentada por Hunt e Thomas em 1999: uma única representação confiável para cada conhecimento.
Conclusão — A Matrix Não Precisava de Mil Smiths
No final de Matrix Reloaded e Matrix Revolutions, Smith tornou-se uma ameaça justamente porque sua capacidade de se replicar saiu do controle.
Na Engenharia de Software acontece algo semelhante.
Cada regra copiada, cada SQL duplicado, cada validação repetida cria mais uma versão da mesma verdade.
E quando a verdade muda, todas as cópias precisam mudar junto.
O princípio DRY nos lembra que software sustentável depende de uma única fonte de conhecimento para cada regra importante.
Para um Programador COBOL que trabalha com IBM Z, isso significa valorizar COPYBOOKs, subprogramas, APIs compartilhadas e componentes reutilizáveis, sempre com equilíbrio e sem criar abstrações artificiais.
No universo Bellacosa Mainframe existe uma máxima que certamente estaria escrita na oficina do Chaveiro:
"Se uma única chave abre todas as portas corretas, cuide bem dela. Construir cem cópias da mesma chave apenas torna mais difícil descobrir qual delas ainda funciona."
Porque, assim como Neo descobriu que um único Escolhido era mais poderoso do que milhares de cópias imperfeitas de Smith, um sistema também se torna muito mais confiável quando cada conhecimento existe em um único lugar, claro, bem documentado e fácil de manter.
Sem comentários:
Enviar um comentário