As 20 Leis Secretas da Matrix da Engenharia de Software (Bizarres Rules)

 

Bellacosa Mainframe e as 20 leis secretas da Engenharia do Software

☕ Um Café no Bellacosa Mainframe

As 20 Leis Secretas da Matrix da Engenharia de Software - Bizarres Rules

O Guia do Programador COBOL Padawan para Sobreviver ao Universo dos Sistemas Legados Sem Ser Absorvido pelo Agente Smith

"Existem duas maneiras de aprender Engenharia de Software. A primeira é passando vinte anos corrigindo bugs em produção. A segunda é ouvindo aqueles que já passaram por isso. Este artigo tenta economizar duas décadas da sua vida."

---

Bem-vindo à Matrix, Padawan

Imagine a seguinte cena.

Você acabou de conseguir seu primeiro emprego como Programador COBOL.

Recebe acesso ao ambiente.

TSO.

ISPF.

CICS.

Db2.

JCL.

Tudo parece misterioso.

Então seu líder aponta para um programa com 180 mil linhas de código.

Ele sorri.

— Pequena manutenção.

Você abre o código.

O ventilador do computador começa a girar mais rápido.

Sua expressão muda.

Você pergunta:

— Quem escreveu isso?

A resposta vem imediatamente.

— Ninguém sabe.

Naquele instante o telefone toca.

É Morpheus.

— Neo... digo... Padawan...

Bem-vindo à Matrix da Engenharia de Software.

---

Existe um lado oculto da programação

Quando começamos a estudar programação, aprendemos:

• IF

• PERFORM

• LOOP

• SQL

• APIs

• Arquivos

• Variáveis

Mas ninguém ensina algo muito mais importante.

Os padrões invisíveis.

Os comportamentos humanos.

Os erros que se repetem geração após geração.

As armadilhas psicológicas.

As decisões arquiteturais.

Essas "leis" não pertencem ao COBOL.

Nem ao Java.

Nem ao Python.

Elas pertencem à natureza humana.

E é justamente por isso que continuam válidas há décadas.

---

A Matrix é feita de padrões

No filme Matrix, Neo acredita que tudo acontece por acaso.

Depois descobre que existem regras invisíveis governando aquele universo.

Na Engenharia de Software acontece exatamente a mesma coisa.

Você acha que aquele sistema virou um caos "do nada".

Não virou.

Ele seguiu um padrão.

Sempre segue.

---

O Oráculo chama isso de experiência

Imagine o Oráculo olhando para um jovem desenvolvedor.

Ela não pergunta:

— Você sabe COBOL?

Ela pergunta:

— Quantas vezes você já viu um sistema quebrar exatamente da mesma forma?

Porque experiência não é decorar comandos.

É reconhecer padrões.

---

Conheça as 20 Leis Secretas da Matrix da Engenharia de Software

Cada uma delas parece engraçada.

Algumas possuem nomes estranhos.

Outras parecem piadas.

Mas todas escondem décadas de aprendizado acumulado.

Vamos atravessar esse espelho.

---

1 — Bus Factor

"E se o único que entende o sistema for atropelado por um ônibus?"

Essa lei nos lembra que conhecimento concentrado é um enorme risco.

Se apenas uma pessoa entende o sistema...

...o sistema pertence a ela.

Não à empresa.

O verdadeiro Jedi documenta.

Compartilha.

Ensina.

https://eljefemidnightlunch.blogspot.com/2020/05/o-fator-onibus-o-dia-em-que-um.html

---

2 — Technical Debt

Toda gambiarra possui juros.

Às vezes ela resolve o problema hoje.

Mas cobra muito mais amanhã.

Como diria o Oráculo:

"A dívida técnica nunca esquece seu endereço."

https://eljefemidnightlunch.blogspot.com/2021/10/technical-debt-rules-quando-um.html 

---

3 — Yak Shaving

Você abriu um chamado simples.

Cinco horas depois.

Está configurando Docker.

Atualizando certificado.

Mudando firewall.

Lendo RFC.

Esqueceu completamente o problema inicial.

Parabéns.

Você encontrou um Yak.

https://eljefemidnightlunch.blogspot.com/2021/09/yak-shaving-rules-quando-um-programador.html

---

4 — Bike Shedding

Reunião de duas horas.

Noventa minutos discutindo a cor do botão.

Cinco minutos falando da arquitetura.

O Agente Smith adora reuniões assim.

https://eljefemidnightlunch.blogspot.com/2021/08/bike-shedding-rules-quando-um.html

---

5 — Golden Hammer

Quando tudo parece prego...

...qualquer ferramenta vira martelo.

O Padawan aprende Java.

Quer resolver tudo com Java.

Aprende IA.

Agora tudo precisa de IA.

Aprende Kubernetes.

Até o bloco de notas vira microsserviço.

Calma.

Nem toda batalha precisa da Nebuchadnezzar.

https://eljefemidnightlunch.blogspot.com/2021/07/golden-hammer-rules-quando-um.html

---

6 — Cargo Cult Programming

CTRL+C.

CTRL+V.

Funcionou.

Mas...

Você sabe por quê?

Se não sabe.

Talvez esteja apenas repetindo um ritual.

Não programação.

https://eljefemidnightlunch.blogspot.com/2021/05/spaghetti-code-rules-quando-um.html

---

7 — Spaghetti Code

IF dentro de IF.

GO TO.

PERFORM.

Mais GO TO.

Mais IF.

O código parece um prato de macarrão.

Delicioso no almoço.

Horrível na manutenção.

https://eljefemidnightlunch.blogspot.com/2021/05/spaghetti-code-rules-quando-um.html

---

8 — Lasagna Code

Agora temos o problema contrário.

Camadas.

Mais camadas.

Mais camadas.

Mais uma camada.

No final.

Um IF precisa atravessar sete microsserviços para mudar um campo.

https://eljefemidnightlunch.blogspot.com/2021/03/lasagna-code-rules-quando-um.html

---

9 — Big Ball of Mud

É aquele sistema onde ninguém sabe explicar a arquitetura.

Funciona?

Funciona.

Como?

Boa pergunta.

https://eljefemidnightlunch.blogspot.com/2021/01/big-ball-of-mud-rules-quando-um.html

---

10 — God Object

Existe um programa chamado:

CLIENTE01.

Ele faz:

• cadastro;

• cobrança;

• PIX;

• cartão;

• empréstimo;

• café;

• provavelmente também controla o clima.

Esse programa acredita ser o Escolhido.

Não é.

https://eljefemidnightlunch.blogspot.com/2020/11/god-object-rules-quando-um-programador.html

---

11 — Lava Flow

Código escrito em 1994.

Ninguém sabe para que serve.

Mas ninguém remove.

Vai que explode.

Então permanece.

Como lava endurecida.

https://eljefemidnightlunch.blogspot.com/2020/12/lava-flow-rules-quando-um-programador.html

---

12 — Boiling Frog

O sistema não piora de um dia para outro.

Vai ficando lentamente mais lento.

Mais complicado.

Mais difícil.

Quando percebemos.

Já estamos mergulhados na água fervendo.

https://eljefemidnightlunch.blogspot.com/2021/11/boiling-frog-rules-quando-um.html

---

13 — Death March

Prazo impossível.

Equipe pequena.

Escopo gigante.

Cliente ansioso.

Café infinito.

Dormir virou luxo.

Esse projeto nunca deveria ter começado assim.

https://eljefemidnightlunch.blogspot.com/2021/02/death-march-project-rules-quando-um.html

---

14 — Brooks's Law

O projeto está atrasado.

A solução?

Contratar vinte pessoas.

Resultado?

Agora existem vinte pessoas tentando entender o sistema.

E o atraso aumenta.

https://eljefemidnightlunch.blogspot.com/2020/09/brookss-law-rules-quando-um-programador.html

---

15 — Conway's Law

As equipes desenham software exatamente como se comunicam.

Se departamentos não conversam.

Os sistemas também não conversarão.

https://eljefemidnightlunch.blogspot.com/2020/08/conways-law-rules-quando-um-programador.html

---

16 — Murphy's Law

Tudo que pode falhar...

Vai falhar.

Especialmente sexta-feira.

Às 18h.

Cinco minutos antes da implantação.

Por isso existem testes.

https://eljefemidnightlunch.blogspot.com/2020/01/murphys-law-quando-um-programador-cobol.html

---

17 — KISS

Se ficou complicado demais...

Provavelmente existe uma solução mais simples.

Os melhores sistemas normalmente parecem óbvios.

Depois de prontos.

https://eljefemidnightlunch.blogspot.com/2020/02/kiss-rules-quando-um-programador-cobol.html

---

18 — YAGNI

"Vai que um dia precisamos..."

Essa frase já criou milhões de linhas de código inútil.

Implemente quando realmente precisar.

https://eljefemidnightlunch.blogspot.com/2020/07/yagni-rules-quando-um-programador-cobol.html

---

19 — DRY

Copiou.

Colou.

Copiou novamente.

Agora o bug existe em dezoito lugares diferentes.

Parabéns.

Você criou um exército de Agentes Smith.

https://eljefemidnightlunch.blogspot.com/2020/06/dry-rules-quando-um-programador-cobol.html

---

20 — SOLID

Os cinco pilares.

O alicerce.

A estrutura.

A arquitetura.

Sem eles.

O software continua funcionando.

Por algum tempo.

Depois...

A Matrix desaba.

https://eljefemidnightlunch.blogspot.com/2020/04/solid-roules-quando-um-programador.html

---

21 — Boy Scout Rule

Sim.

Ela veio depois.

Porque nenhum sistema melhora sozinho.

Toda vez que tocar em um programa.

Deixe-o um pouco melhor.

Nem que seja apenas renomeando uma variável.

https://eljefemidnightlunch.blogspot.com/2020/03/boy-scout-rule-quando-um-programador.html

---

O verdadeiro inimigo nunca foi a tecnologia

Perceba algo curioso.

Nenhuma dessas leis fala de:

COBOL.

Java.

Python.

Rust.

Go.

Todas falam sobre pessoas.

Porque software é uma atividade humana.

---

O Agente Smith mora dentro da nossa cabeça

Smith aparece quando pensamos:

• "Depois eu arrumo."

• "Só desta vez."

• "Ninguém vai perceber."

• "Pode copiar."

• "Não precisa documentar."

• "Vai funcionar."

É exatamente assim que grandes sistemas envelhecem.

---

Neo nunca venceu sozinho

Observe Matrix novamente.

Neo nunca salvou o mundo sozinho.

Precisou de:

• Morpheus;

• Trinity;

• Oráculo;

• Link;

• Tank;

• Niobe;

• Sati;

• Chaveiro.

Grandes sistemas também são construídos por equipes.

---

E onde entra o COBOL?

Em todos os lugares.

Os sistemas COBOL que movimentam bancos, seguradoras, bolsas de valores e governos não sobreviveram cinquenta anos porque alguém escreveu um código perfeito.

Eles sobreviveram porque milhares de engenheiros aplicaram — muitas vezes sem conhecer os nomes — esses princípios ao longo das décadas:

• simplificaram;

• documentaram;

• removeram duplicações;

• dividiram responsabilidades;

• testaram;

• compartilharam conhecimento;

• fizeram pequenas melhorias contínuas.

É por isso que um programa COBOL de 1988 ainda pode estar processando milhões de transações diariamente.

---

O Convite do Oráculo

No final da jornada, o Oráculo entrega a Neo um pequeno caderno.

Na capa está escrito:

"As Leis Secretas da Engenharia de Software."

Neo pergunta:

— Depois que eu decorar todas elas, finalmente serei um grande programador?

Ela sorri.

— Não.

— Então para que servem?

Ela responde:

"Porque agora, quando encontrar um problema, você saberá dar um nome ao monstro. E quando um monstro tem nome, ele deixa de parecer invencível."

---

Continue Explorando a Matrix

Se este artigo despertou sua curiosidade, esta é apenas a porta de entrada.

Cada uma dessas vinte (e uma) regras esconde uma história fascinante, repleta de exemplos reais, armadilhas clássicas, curiosidades históricas e lições que moldaram a engenharia de software moderna.

Nos próximos artigos da série ☕ Um Café no Bellacosa Mainframe, vamos mergulhar em cada uma delas com profundidade, sempre sob a ótica de um Programador COBOL Padawan explorando os corredores da Matrix.

Você descobrirá por que projetos fracassam, como sistemas sobrevivem por décadas, o que diferencia arquiteturas elegantes de verdadeiros labirintos de código e, principalmente, como transformar conhecimento técnico em sabedoria prática.

A cada regra desvendada, você enxergará um pouco mais do código verde da Matrix.

---

Conclusão — A Matrix Sempre Esteve na Engenharia de Software

No primeiro filme, Morpheus diz a Neo que a Matrix está em toda parte.

Na Engenharia de Software acontece exatamente o mesmo.

Essas leis aparecem:

• em pequenos scripts;

• em APIs modernas;

• em aplicações mobile;

• em microsserviços;

• em sistemas bancários;

• em programas COBOL escritos há quarenta anos;

• e até nas respostas geradas por Inteligências Artificiais.

Elas não são modismos.

São observações acumuladas por milhares de engenheiros que erraram, aprenderam, compartilharam e deixaram um mapa para quem veio depois.

Talvez você ainda não tenha encontrado todas essas situações.

Mas, acredite, se continuar programando, elas encontrarão você.

A boa notícia é que, agora, você já conhece seus nomes.

E isso faz toda a diferença.

No universo Bellacosa Mainframe, existe uma última frase escrita na parede da sala do Arquiteto:

"Todo Padawan começa aprendendo comandos. Todo Mestre termina reconhecendo padrões. Porque linguagens mudam, tecnologias envelhecem e frameworks desaparecem, mas as leis da Engenharia de Software continuam governando a Matrix muito depois que o último deploy termina."

Então pegue seu café.

Abra seu editor COBOL.

E venha explorar essas estranhas, divertidas e surpreendentemente verdadeiras regras da Engenharia de Software.

A Matrix está esperando por você.

God Object Rules: Quando um Programador COBOL Descobriu que Nem Mesmo o Arquiteto da Matrix Deveria Controlar Tudo Sozinho

 

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, Helper ou Util que 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.

SOLID Rules : Quando um Programador COBOL Descobriu que a Matrix Não Permanecia de Pé por Magia… Mas Porque Seus Alicerces Seguiam Cinco Princípios Fundamentais

 

Bellacosa Mainframe apresenta solid rules

☕ Um Café no Bellacosa Mainframe

SOLID Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Não Permanecia de Pé por Magia… Mas Porque Seus Alicerces Seguiam Cinco Princípios Fundamentais

"Construir software é como construir Zion. O segredo não está apenas nas paredes. Está nos pilares invisíveis que impedem tudo de desabar."

---

Prólogo — Os Cinco Pilares da Matrix

Depois de atravessar inúmeras versões da Matrix, Neo finalmente chegou ao salão mais antigo da Cidade das Máquinas.

Ao contrário do que imaginava, não encontrou processadores gigantes nem supercomputadores.

No centro da sala havia apenas cinco colunas de cristal.

Cada uma emitia uma luz diferente.

Neo perguntou ao Arquiteto:

— O que sustentam essas colunas?

O Arquiteto respondeu:

— Tudo.

Neo olhou ao redor.

— A Matrix inteira?

— Sim.

Neo aproximou-se da primeira coluna.

Nela estava gravado:

S

Na segunda.

O

Na terceira.

L

Na quarta.

I

Na quinta.

D

O Oráculo apareceu com duas xícaras de café.

Entregou uma para Neo.

Depois disse:

"A maioria dos programadores acredita que grandes sistemas sobrevivem porque foram escritos por pessoas inteligentes. Na verdade, eles sobrevivem porque foram construídos sobre princípios inteligentes."

Neo percebeu que aquelas cinco letras sustentavam toda a Matrix.

---

O que é SOLID?

SOLID é um conjunto de cinco princípios de projeto de software que ajudam a criar sistemas:

• fáceis de entender;

• fáceis de manter;

• fáceis de evoluir;

• menos propensos a bugs;

• mais preparados para mudanças.

Embora tenham surgido no contexto da programação orientada a objetos, seus conceitos são muito mais amplos e podem ser aplicados a COBOL, CICS, Db2, APIs, microsserviços, arquitetura corporativa e praticamente qualquer tecnologia.

---

A origem do SOLID

Os princípios foram sendo formulados por Robert C. Martin, conhecido mundialmente como Uncle Bob, durante as décadas de 1990 e 2000.

O acrônimo SOLID foi posteriormente organizado por Michael Feathers, reunindo cinco ideias fundamentais:

• S – Single Responsibility Principle

• O – Open/Closed Principle

• L – Liskov Substitution Principle

• I – Interface Segregation Principle

• D – Dependency Inversion Principle

Esses princípios tornaram-se referência mundial para arquitetura e design de software.

---

Matrix explica perfeitamente

Imagine que cada um dos cinco pilares da Matrix seja removido.

Primeiro.

As responsabilidades ficam confusas.

Depois.

Toda mudança exige alterar tudo.

Em seguida.

Componentes deixam de ser compatíveis.

Depois.

Interfaces tornam-se enormes.

Por fim.

Tudo depende diretamente de tudo.

Resultado.

A Matrix entra em colapso.

---

Primeiro Pilar — S

Single Responsibility Principle (SRP)

Uma classe, módulo ou programa deve possuir apenas um motivo para mudar.

---

O COBOL entende isso perfeitamente

Imagine um programa chamado:

CLIENTE01

Ele:

• cadastra clientes;

• calcula empréstimos;

• imprime boletos;

• envia e-mails;

• atualiza estoque;

• gera PIX.

Quantas responsabilidades existem?

Muitas.

Se qualquer uma mudar.

O programa inteiro muda.

---

Matrix

Neo pergunta.

— Quem controla Zion?

O Oráculo responde.

— Todo mundo.

Resultado?

Ninguém sabe quem é responsável.

---

Segundo Pilar — O

Open/Closed Principle (OCP)

Software deve estar aberto para extensão e fechado para modificação.

---

Em vez de alterar código antigo.

Criamos novas funcionalidades.

---

Exemplo COBOL

Criar um novo subprograma para um novo cálculo.

Não modificar dezenas de programas antigos.

---

Matrix

Em vez de reconstruir toda a Matrix.

O Arquiteto cria uma nova versão.

---

Terceiro Pilar — L

Liskov Substitution Principle (LSP)

Criado por Barbara Liskov, vencedora do Prêmio Turing.

A ideia.

Componentes derivados devem poder substituir seus componentes originais sem quebrar o sistema.

---

Mesmo em COBOL.

Isso significa.

Módulos equivalentes devem respeitar os mesmos contratos.

---

Matrix

Se Neo substitui um operador da Matrix.

O restante não deve perceber.

---

Quarto Pilar — I

Interface Segregation Principle (ISP)

Não obrigue consumidores a depender de funcionalidades que não utilizam.

---

Exemplo

Uma API com:

300 operações.

Quando seu programa usa apenas duas.

---

COBOL

COPYBOOK gigantesco.

Quando o programa utiliza apenas cinco campos.

---

Matrix

Neo recebe um painel com mil botões.

Mas usa apenas três.

---

Quinto Pilar — D

Dependency Inversion Principle (DIP)

Módulos de alto nível não devem depender diretamente dos de baixo nível.

Ambos devem depender de abstrações.

---

COBOL

Em vez de acessar diretamente um arquivo específico.

Criar uma camada de acesso.

---

Matrix

Neo não precisa saber onde está cada cabo da Matrix.

Ele conversa com interfaces.

---

O efeito psicológico

Programadores iniciantes gostam de resolver problemas rapidamente.

Programadores experientes pensam.

"Como alguém manterá isso daqui a dez anos?"

Essa é a essência do SOLID.

---

O Programador COBOL Padawan

Você recebe um programa com:

18 mil linhas.

120 PERFORMs.

90 IFs.

40 GO TO.

Depois pergunta.

— Podemos dividir?

Resposta.

"Não mexe."

SOLID começa exatamente aí.

---

O Agente Smith odeia SOLID

Porque SOLID reduz:

• duplicação;

• acoplamento;

• bugs;

• retrabalho.

Quanto melhor a arquitetura.

Menos espaço existe para o caos.

---

Matrix Reloaded

Observe.

O Oráculo.

O Arquiteto.

O Chaveiro.

Cada personagem possui uma responsabilidade clara.

Nenhum tenta fazer o trabalho do outro.

Essa divisão é um excelente exemplo do primeiro princípio.

---

SOLID no universo IBM Z

Embora muitos associem SOLID apenas a Java ou C#, seus conceitos aparecem naturalmente no ecossistema IBM Z.

Por exemplo:

SRP

• Programas COBOL menores.

• Serviços CICS especializados.

• Jobs batch com uma finalidade clara.

OCP

• Inclusão de novos produtos por parametrização.

• Novos módulos de cálculo.

• Regras externas em tabelas.

LSP

• Subprogramas intercambiáveis.

• APIs mantendo contratos compatíveis.

• Serviços reutilizáveis.

ISP

• COPYBOOKs específicos.

• APIs enxutas.

• Mensagens MQ contendo apenas o necessário.

DIP

• Camadas de acesso ao Db2.

• Encapsulamento de VSAM.

• APIs REST desacoplando consumidores da implementação interna.

---

Curiosidade

Uncle Bob nunca afirmou que SOLID resolve todos os problemas.

Na verdade.

Ele sempre reforçou que princípios são ferramentas de raciocínio.

Não regras absolutas.

---

Atenção!

Aplicar SOLID em excesso também pode gerar problemas.

Sistemas pequenos.

Podem tornar-se desnecessariamente complexos.

O segredo.

É equilíbrio.

---

SOLID conversa com toda esta série

Observe como os princípios estudados anteriormente convergem naturalmente para SOLID.

KISS

Ajuda o SOLID a permanecer simples.

---

DRY

Evita duplicação entre responsabilidades.

---

YAGNI

Impede abstrações desnecessárias.

---

Lava Flow

É reduzido por módulos pequenos.

---

Spaghetti Code

Desaparece quando responsabilidades são claras.

---

God Object

É praticamente o oposto do SRP.

---

Lasagna Code

É combatido quando abstrações possuem propósito.

---

Ferramentas ajudam

Hoje temos:

• SonarQube.

• IBM ADDI.

• COBOL Check.

• Enterprise Analyzer.

• Architecture Decision Records (ADR).

• Revisões de Código.

Todas ajudam a medir qualidade arquitetural.

---

O papel da IA

A IA consegue:

• sugerir refatorações;

• dividir módulos grandes;

• detectar responsabilidades misturadas;

• localizar acoplamentos.

Mas apenas arquitetos humanos compreendem profundamente o domínio do negócio.

---

Os riscos

Ignorar SOLID gera:

• programas gigantes;

• manutenção cara;

• regressões;

• dificuldade de testes;

• baixo reaproveitamento;

• arquitetura rígida.

---

Erros clássicos

• Um programa faz tudo.

• Alterar código antigo continuamente.

• Interfaces enormes.

• Dependências diretas.

• Acoplamento excessivo.

---

Boas práticas

• Dividir responsabilidades.

• Criar contratos claros.

• Favorecer composição.

• Reduzir acoplamento.

• Escrever módulos pequenos.

• Refatorar continuamente.

• Documentar decisões arquiteturais.

---

Um exemplo inspirado na Matrix

Imagine construir Zion.

Uma única pessoa seria responsável por:

• energia;

• defesa;

• alimentação;

• medicina;

• transporte.

Parece absurdo.

Mas muitos sistemas são exatamente assim.

---

O ensinamento do Oráculo

O Oráculo leva Neo até as cinco colunas novamente.

Depois remove uma delas.

Toda a estrutura começa a vibrar.

Ela pergunta.

— Qual era a mais importante?

Neo observa.

Depois responde.

— Nenhuma.

Todas.

Ela sorri.

"Grandes sistemas não sobrevivem por causa de um único princípio. Eles sobrevivem pelo equilíbrio entre todos eles."

---

Lições para um Programador COBOL Padawan

Ao longo da sua carreira, você perceberá que escrever um programa que funcione é apenas o primeiro passo.

O verdadeiro desafio é escrever um programa que continue funcionando e possa evoluir durante vinte ou trinta anos.

Sempre que iniciar uma nova funcionalidade, faça algumas perguntas:

• Este programa possui apenas uma responsabilidade?

• Posso adicionar novas funcionalidades sem alterar tudo?

• Estou respeitando contratos existentes?

• Minha interface é realmente necessária ou ficou grande demais?

• Estou acoplado diretamente a detalhes de implementação?

Essas perguntas farão enorme diferença quando o sistema crescer.

---

Curiosidades

Embora SOLID tenha sido popularizado na orientação a objetos, seus princípios influenciaram:

• Arquitetura Hexagonal.

• Clean Architecture.

• Domain-Driven Design.

• Microsserviços.

• APIs REST.

• Engenharia de Software Ágil.

• DevOps.

• Engenharia de Plataformas.

Todos compartilham a mesma ideia:

software preparado para mudança.

---

Conclusão — Os Cinco Pilares Que Mantêm a Matrix de Pé

Quando Neo entrou no núcleo da Matrix, imaginou encontrar máquinas extraordinárias.

Em vez disso, encontrou cinco princípios.

Foi uma metáfora poderosa.

Na Engenharia de Software acontece exatamente o mesmo.

Ferramentas mudam.

Linguagens evoluem.

Frameworks surgem e desaparecem.

Mas princípios sólidos continuam relevantes por décadas.

Para um Programador COBOL que trabalha com IBM Z, isso significa escrever programas claros, bem divididos, desacoplados e preparados para evoluir conforme o negócio muda.

SOLID não é uma receita pronta.

É uma forma de pensar.

Uma forma de projetar sistemas que resistem ao tempo, às mudanças de requisitos e às inevitáveis transformações tecnológicas.

No universo Bellacosa Mainframe existe uma máxima que certamente estaria gravada nas colunas do núcleo da Matrix:

"Tecnologias envelhecem. Frameworks desaparecem. Linguagens evoluem. Mas sistemas construídos sobre princípios sólidos continuam sustentando o mundo muito depois de seus criadores terem deixado o teclado."

Porque, no fim, o verdadeiro Escolhido não é quem escreve o código mais complexo.

É quem constrói software que a próxima geração conseguirá compreender, evoluir e manter vivo por muitas décadas.