 |
| 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.
Sem comentários:
Enviar um comentário