 |
| Bellacosa Mainframe e a god object rules |
☕ Um Café no Bellacosa Mainframe
God Object Rules sem Mistérios
Quando um Programador COBOL Descobriu que Nem Mesmo o Arquiteto da Matrix Deveria Controlar Tudo Sozinho
"Todo sistema precisa de liderança. Nenhum sistema sobrevive quando uma única entidade tenta fazer absolutamente tudo."
Prólogo — O Programa que Governava Toda a Matrix
Neo caminhava pelos corredores infinitos da Matrix.
Depois de atravessar dezenas de portas, finalmente chegou até a sala do Arquiteto.
Mas desta vez havia algo diferente.
No centro da sala existia apenas um gigantesco programa.
Seu nome era:
SYSTEM-CORE-MASTER-PROCESSOR-UNIVERSAL
Neo perguntou:
— O que esse programa faz?
O Arquiteto respondeu calmamente.
— Tudo.
Neo estranhou.
— Tudo?
— Sim.
Ele:
autentica usuários;
calcula empréstimos;
processa PIX;
envia e-mails;
controla cartões;
consulta saldo;
gera boletos;
grava auditoria;
imprime relatórios;
conversa com APIs;
envia mensagens MQ;
acessa o Db2;
manipula VSAM;
chama CICS;
controla segurança;
gera logs;
cria arquivos;
calcula impostos;
fecha o mês;
abre o dia.
Neo ficou em silêncio.
Olhou para o tamanho do programa.
412.873 linhas
Morpheus respirou profundamente.
— Neo...
você acaba de encontrar um God Object.
O que é God Object?
God Object (Objeto Deus) é um antipadrão onde um único componente concentra responsabilidades demais.
Ele conhece tudo.
Controla tudo.
Decide tudo.
Depende de todos.
E todos dependem dele.
Em Programação Orientada a Objetos normalmente é uma classe gigantesca.
No universo COBOL, normalmente aparece como:
um programa enorme;
um módulo central;
um "programa mestre";
um controlador universal.
A origem do termo
O conceito surgiu durante a popularização da Programação Orientada a Objetos nos anos 80 e 90.
Quando OO começou a crescer, percebeu-se que muitos desenvolvedores criavam classes responsáveis por praticamente todo o sistema.
Essas classes violavam praticamente todos os princípios de bom projeto.
Receberam então o apelido de:
God Object
Porque pareciam onipresentes.
Matrix explica isso perfeitamente
Durante boa parte da trilogia acreditamos que:
O Arquiteto controla tudo.
Depois descobrimos que não.
Existe também:
Oráculo
Merovíngio
Chaveiro
Agentes
Programas independentes
Sentinelas
Cada um possui responsabilidades diferentes.
Imagine se apenas o Arquiteto tentasse executar tudo sozinho.
A Matrix entraria em colapso.
O nascimento do God Object
Curiosamente...
ele costuma nascer de uma boa intenção.
Primeira versão.
Programa de Clientes
Depois.
"Vamos colocar autenticação."
Depois.
"Aproveita e grava log."
Depois.
"Já calcula limite."
Depois.
"Também envia e-mail."
Depois.
"Também atualiza cartão."
Depois.
"Também consulta PIX."
Cinco anos depois.
O programa virou um universo inteiro.
O COBOL conhece isso muito bem
Imagine um programa chamado:
CLIENTE01
Originalmente fazia apenas cadastro.
Anos depois passou a:
consultar saldo;
emitir extratos;
calcular tarifas;
atualizar endereço;
validar CPF;
gerar auditoria;
integrar Open Finance;
enviar SMS;
gerar arquivos CNAB.
O nome permaneceu.
A responsabilidade desapareceu.
Um exemplo simples
Arquitetura saudável.
CLIENTE
↓
Cadastro
↓
Consulta
↓
Atualização
Agora.
God Object.
CLIENTE
↓
Tudo.
O efeito psicológico
Existe uma razão interessante.
Nosso cérebro gosta de centralizar.
Quando surge uma nova funcionalidade pensamos.
"Vou colocar aqui mesmo."
É mais rápido.
Mais fácil.
Mais conveniente.
Até deixar de ser.
Matrix Reloaded
Imagine Neo.
Cada novo poder descoberto.
Voar.
Parar balas.
Ler código.
Controlar máquinas.
Agora imagine.
Além disso.
Ele também:
pilota a nave.
Conserta motores.
Programa a Matrix.
Opera comunicações.
Faz medicina.
Cozinha.
Conserta o Db2.
Absurdo.
Mas exatamente isso acontece com um God Object.
Como reconhecer?
Existem sinais clássicos.
Programa enorme
Dezenas de milhares de linhas.
Muitas responsabilidades
Faz tudo.
Muitas dependências
Conhece dezenas de módulos.
Muitas chamadas
Todo mundo depende dele.
Alterações frequentes
Sempre muda.
Porque tudo passa por ele.
O Agente Smith adora isso
Porque basta derrubar um único componente.
Todo o sistema sofre.
É um enorme ponto único de falha.
Um exemplo COBOL
Programa:
PGMCORE
Ele:
acessa Db2;
grava VSAM;
chama MQ;
consulta REST;
gera XML;
gera JSON;
controla autenticação;
calcula impostos;
imprime relatórios.
Pergunta.
Qual é sua responsabilidade?
Resposta.
Todas.
O custo invisível
Nova regra.
Antes.
Alterava um programa.
Agora.
Precisa entender:
80 mil linhas.
O impacto no Mainframe
Quanto maior o God Object.
Maior:
CPU;
tempo de compilação;
tempo de testes;
risco;
dependência.
Existe God Object em arquitetura?
Sim.
Às vezes não é um programa.
É um microsserviço.
Chamado:
CoreService.
Ele atende:
todos.
Isso também é um God Object.
A diferença
Módulo central.
↓
Coordena.
God Object.
↓
Executa tudo.
O papel do Arquiteto
O verdadeiro arquiteto distribui responsabilidades.
Nunca concentra.
O princípio SOLID
God Object viola vários princípios.
Principalmente.
SRP
Single Responsibility Principle.
Um módulo.
Uma responsabilidade.
Matrix e o Oráculo
O Oráculo não tenta controlar toda a Matrix.
Ela aconselha.
O Chaveiro cuida das chaves.
O Merovíngio controla informações.
Cada programa possui função específica.
Essa divisão torna o sistema resiliente.
Como evitar?
Modularização
Divida funções.
CALL
Extraia responsabilidades.
APIs
Separe serviços.
COPYBOOK
Compartilhe estruturas.
Não comportamento.
Refatoração
Remova responsabilidades pouco a pouco.
Revisões
Questione sempre.
"Esse módulo realmente deveria fazer isso?"
Atenção!
Existe uma diferença importante.
Um programa pode ser grande.
Sem ser God Object.
O problema não é o tamanho.
É a quantidade de responsabilidades.
Curiosidade
Muitos sistemas bancários antigos possuem programas chamados:
MASTER
CORE
MAIN
CONTROL
MANAGER
Nem todos são God Objects.
Mas muitos acabaram se tornando.
O perigo
Acoplamento
Tudo depende dele.
Baixa reutilização
Funções ficam escondidas.
Testes difíceis
Cenários infinitos.
Deploy arriscado
Qualquer alteração afeta tudo.
Conhecimento concentrado
Poucas pessoas entendem.
Um exemplo inspirado na Matrix
Imagine.
Existe apenas um personagem.
Ele é:
Arquiteto.
Oráculo.
Neo.
Trinity.
Smith.
Merovíngio.
Chaveiro.
Todos ao mesmo tempo.
A história seria impossível.
Software também.
Ferramentas ajudam
Hoje conseguimos identificar God Objects usando:
SonarQube
IBM ADDI
IBM Application Discovery
Enterprise Analyzer
IBM COBOL Check
Elas medem:
acoplamento;
complexidade;
dependências;
tamanho;
responsabilidades.
O papel da IA
IA consegue identificar:
métodos enormes.
Dependências.
Objetos excessivos.
Mas ainda depende da análise humana para decidir como dividir responsabilidades.
Aplicabilidade
God Object aparece em:
COBOL
Java
C#
Python
PHP
JavaScript
Microsserviços
APIs
Cloud
Nenhuma tecnologia escapa.
Erros clássicos
Colocar tudo no mesmo programa.
Misturar negócio com infraestrutura.
Misturar interface com persistência.
Acrescentar funcionalidades indefinidamente.
Evitar modularização.
Boas práticas
Alta coesão.
Baixo acoplamento.
Uma responsabilidade.
Pequenas funções.
Interfaces claras.
Código reutilizável.
Documentação.
O ensinamento do Oráculo
O Oráculo entrega um espelho para Neo.
Ele olha.
Vê apenas um rosto.
Depois o espelho se quebra.
Agora aparecem centenas de pequenos espelhos.
Ela pergunta.
"Qual deles é mais resistente?"
Neo responde.
"Os pequenos."
Ela sorri.
"Quando um quebra, os outros continuam refletindo."
Essa é exatamente a ideia da arquitetura modular.
Lições para um Programador COBOL Padawan
Ao longo da carreira, você encontrará programas que parecem controlar o universo inteiro. A tentação será continuar acrescentando funcionalidades porque "já existe muita coisa ali".
Resista.
Sempre que possível:
identifique responsabilidades distintas;
extraia regras para módulos especializados;
separe acesso a dados das regras de negócio;
utilize programas chamados (
CALL) para funcionalidades reutilizáveis;mantenha interfaces simples e bem definidas.
Cada responsabilidade removida de um God Object reduz riscos, facilita testes e torna o sistema mais compreensível.
Curiosidades
O antipadrão God Object possui "parentes" famosos:
Blob – um objeto gigante rodeado de objetos quase vazios.
God Class – termo usado em Java e C# para classes com centenas de métodos.
Swiss Army Knife Class – classe que tenta oferecer uma ferramenta para qualquer situação.
Manager Mania – classes chamadas
Manager,HelperouUtilque acabam concentrando comportamento demais.
Todos compartilham a mesma característica: excesso de responsabilidades.
Conclusão — Nem Mesmo o Arquiteto Controlava Tudo
No universo Matrix existe uma lição fascinante.
Embora o Arquiteto parecesse controlar toda a simulação, ele não fazia tudo sozinho. A estabilidade do sistema dependia da colaboração entre diversas entidades, cada uma especializada em uma função.
A Engenharia de Software segue exatamente esse princípio.
Quando um único programa COBOL, uma classe Java ou um microsserviço tenta assumir todas as responsabilidades, ele se transforma em um God Object. No início parece eficiente. Depois torna-se pesado, difícil de testar, arriscado de modificar e praticamente impossível de compreender.
Para um Programador COBOL, especialmente em ambientes IBM Z que processam milhões de transações críticas, a maior virtude não é escrever o maior programa da empresa.
É construir componentes pequenos, coesos, bem definidos e capazes de cooperar entre si.
No universo Bellacosa Mainframe existe uma máxima digna do Oráculo:
"Um sistema forte não nasce de um único programa poderoso. Nasce de muitos módulos simples que sabem exatamente qual é sua missão."
Porque até a Matrix precisou aprender que nenhum programa deveria tentar ser um deus.
Sem comentários:
Enviar um comentário