 |
| Bellacosa Mainframe e o spaghetti code rules |
☕ Um Café no Bellacosa Mainframe
Spaghetti Code Rules sem Mistérios
Quando um Programador COBOL Descobriu que a Matrix Era Feita de Espaguete e Cada GO TO Criava um Novo Labirinto
"A Matrix não aprisionava apenas pessoas. Ela também aprisionava programas dentro de um emaranhado de caminhos onde ninguém mais sabia como chegar à saída."
Prólogo — O Labirinto Invisível da Matrix
Neo acabara de receber uma missão aparentemente simples.
Corrigir um erro no cálculo dos juros de um financiamento.
Morpheus entregou um único arquivo.
FINANCEIRO01.CBL
Neo sorriu.
— Apenas um programa?
Morpheus respondeu.
— Sim.
Só um.
Neo abriu o código.
A barra de rolagem diminuiu.
Muito.
Muito mesmo.
O programa possuía:
68.000 linhas
2.400 parágrafos
centenas de
GO TOdezenas de
ALTERmilhares de variáveis
comentários escritos por gerações diferentes
Neo tentou localizar a regra do financiamento.
Cinco minutos depois...
estava em outra rotina.
Dez minutos depois...
entrou em um PERFORM.
Depois um GO TO.
Depois outro.
Depois um PERFORM THRU.
Depois um ALTER.
Depois um EXIT.
Depois voltou.
Depois foi para outro programa.
Depois retornou.
Finalmente perguntou:
— Morpheus...
onde exatamente começa esse cálculo?
Morpheus sorriu.
— Essa pergunta já foi feita por pelo menos cinquenta programadores antes de você.
O Oráculo apareceu.
Olhou para Neo.
E disse:
"Você não entrou apenas em um programa. Entrou em um prato de espaguete."
O que é Spaghetti Code?
Spaghetti Code (Código Espaguete) é um antipadrão de software caracterizado por uma estrutura extremamente confusa, onde o fluxo de execução é difícil de compreender, seguir ou modificar.
O nome vem da aparência do fluxo lógico.
Imagine um prato cheio de espaguete.
Os fios cruzam-se em todas as direções.
Você tenta puxar um.
Leva metade do prato junto.
No software acontece exatamente igual.
Uma alteração aparentemente simples afeta dezenas de outras partes.
A origem do termo
O termo surgiu na década de 1970.
Naquela época muitos sistemas eram escritos utilizando:
GOTO
Jumps
Branches
Fluxos não estruturados
Os diagramas de execução pareciam literalmente um prato de macarrão.
Daí nasceu o nome.
Matrix explica melhor que qualquer livro
Imagine que Neo precisa chegar até o Arquiteto.
Mas cada corredor leva para outro corredor.
Cada porta abre outra porta.
Cada elevador muda de direção.
Cada escolha cria um novo caminho.
Após meia hora...
Neo percebe.
A Matrix inteira virou um labirinto.
É exatamente essa sensação que um desenvolvedor experimenta ao abrir um sistema com Spaghetti Code.
O nascimento do espaguete
Curiosamente...
ninguém acorda pensando:
"Hoje vou criar um código horrível."
O Spaghetti Code nasce lentamente.
Primeiro.
Um pequeno ajuste.
Depois.
Outro.
Depois.
Uma exceção.
Depois.
Uma regra temporária.
Depois.
Outra urgência.
Depois.
Uma correção rápida.
Cinco anos depois...
o prato está servido.
Um exemplo COBOL
Imagine este fluxo.
INICIO
↓
VALIDA
↓
CALCULA
↓
GRAVA
↓
FIM
Bonito.
Agora imagine vinte anos depois.
INICIO
↓
VALIDA
↓
GO TO ROTINA-X
↓
PERFORM Y
↓
ALTER Z
↓
GO TO A
↓
PERFORM THRU B
↓
ROTINA-C
↓
GO TO D
↓
VALIDA NOVAMENTE
↓
VOLTA
↓
FIM
Ninguém mais entende.
Como surge?
Existem várias causas.
Crescimento contínuo
Programa pequeno.
Depois médio.
Depois enorme.
Falta de arquitetura
Cada desenvolvedor cria sua própria organização.
Pressão por prazo
"Depois organizamos."
Nunca organizam.
Excesso de GO TO
O clássico dos clássicos.
Código duplicado
Trechos espalhados.
Ausência de revisão
Ninguém verifica consistência.
O COBOL é culpado?
Não.
Essa talvez seja a maior injustiça da história da computação.
COBOL moderno incentiva:
PERFORM
Modularização
COPYBOOK
CALL
Programas estruturados
Classes
Métodos (Enterprise COBOL moderno)
O problema nunca foi COBOL.
Foi a forma como algumas pessoas programaram.
Matrix Reloaded
O Arquiteto mostra milhares de versões anteriores da Matrix.
Cada versão acumulava pequenos remendos.
Nenhum parecia perigoso.
Todos juntos criaram enorme complexidade.
Software evolui exatamente assim.
O efeito psicológico
Existe uma armadilha.
Quando modificamos um programa conhecido.
Pensamos:
"Vou colocar só mais um IF."
Depois outro.
Depois outro.
Cada alteração parece pequena.
A soma delas não é.
O Programador COBOL Padawan
Todo Padawan abre um programa antigo e pensa.
"Vou entender rapidamente."
Uma hora depois.
Ainda tenta descobrir onde começou.
O Agente Smith adora Spaghetti Code
Porque sistemas confusos criam:
medo.
Ninguém gosta de alterar.
Cada mudança parece perigosa.
Smith nem precisa atacar.
O próprio código afasta os desenvolvedores.
Um exemplo inspirado na Matrix
Imagine que Neo precisa abrir uma porta.
Mas antes precisa:
abrir outra.
Depois outra.
Depois voltar.
Depois pegar uma chave.
Depois retornar.
Depois abrir outra porta.
É exatamente isso que acontece em muitos fluxos de programas antigos.
Como reconhecer?
Existem sinais claros.
Muitos GO TO
Principal indicador.
Programas enormes
30 mil.
50 mil.
100 mil linhas.
Variáveis sem significado
A1
B2
X99
WK01
WK02
WK03
Regras espalhadas
Mesmo cálculo aparece em cinco lugares.
Dependências circulares
Programa chama outro.
Que chama outro.
Que volta ao primeiro.
Um caso realista
Imagine.
Sistema bancário.
Criado em:
Mais de:
400 modificações.
Nenhuma refatoração.
Resultado.
Cada alteração exige:
dois analistas
três programadores
uma semana de testes
Não porque a regra seja difícil.
Mas porque ninguém sabe o impacto.
Os riscos
Bugs
Alteração pequena.
Impacto gigante.
Performance
Fluxo desnecessário.
CPU
Mais instruções.
Mais custo.
Manutenção
Tempo explode.
Onboarding
Novos profissionais sofrem.
Burnout
Especialistas tornam-se gargalos.
O custo invisível
Imagine.
Alteração.
15 minutos.
Mas entender o programa leva:
dois dias.
Isso é custo.
O impacto no Mainframe
Mainframe processa:
milhões de transações.
Spaghetti Code aumenta:
CPU
consumo
risco
testes
tempo de homologação
Tudo fica mais caro.
Existe ferramenta para medir?
Sim.
Hoje existem ferramentas excelentes.
IBM ADDI
IBM Application Discovery
SonarQube
IBM COBOL Check
IBM Developer for z/OS
Enterprise Analyzer
Elas calculam:
complexidade ciclomática
dependências
acoplamento
fluxo
Como evitar?
Modularização
Divida responsabilidades.
PERFORM
Prefira estruturas claras.
CALL
Separe funcionalidades.
COPYBOOK
Padronize estruturas.
Refatoração contínua
Não espere dez anos.
Comentários úteis
Explique:
por quê.
Não:
o quê.
Testes
Protegem refatorações.
Atenção!
Existe diferença entre:
Programa grande
e
Spaghetti Code.
Alguns sistemas possuem:
200 mil linhas.
Mas excelente organização.
Outros possuem:
2 mil linhas.
Completamente caóticos.
O tamanho não define qualidade.
O papel da arquitetura
Arquitetura cria limites.
Cada módulo possui função.
Sem arquitetura.
Tudo conversa com tudo.
Matrix e os Sentinelas
Os Sentinelas encontram Zion porque seguem caminhos claros.
Imagine se existissem milhões de túneis aleatórios.
Eles demorariam muito mais.
Código também.
Fluxos claros facilitam manutenção.
Curiosidade
A Structured Programming Movement dos anos 70 surgiu justamente para combater o Spaghetti Code.
Nomes como:
Edsger Dijkstra
Niklaus Wirth
Donald Knuth
mudaram completamente a forma de programar.
O famoso artigo:
"Go To Statement Considered Harmful"
transformou a indústria.
O COBOL moderno
Enterprise COBOL oferece recursos para escrever código extremamente limpo.
Inline PERFORM
EVALUATE
Functions
Nested Programs
OO COBOL
User Defined Functions
XML
JSON
Não existe desculpa para criar espaguete.
Erros clássicos
Misturar regras de negócio e acesso a dados.
Usar GO TO excessivamente.
Duplicar lógica.
Não remover código morto.
Acrescentar IFs infinitamente.
Não modularizar.
Boas práticas
Uma responsabilidade por módulo.
Nomes significativos.
Fluxo previsível.
Revisões frequentes.
Refatoração incremental.
Diagramas atualizados.
Documentação viva.
O Ensinamento do Oráculo
O Oráculo entrega um prato de espaguete para Neo.
Ele tenta puxar um fio.
Todo o prato vem junto.
Ela então entrega uma caixa organizada de peças LEGO.
Cada bloco possui uma função.
Ela sorri.
"Software deve parecer LEGO.
Nunca espaguete."
Aplicabilidade
Spaghetti Code aparece em:
COBOL
Java
Python
C
C++
JavaScript
PHP
Rust
Go
Assembly
Nenhuma linguagem está imune.
Lições para um Programador COBOL Padawan
Quando você começar sua carreira em um ambiente IBM Z, encontrará programas escritos há décadas. Alguns serão verdadeiras obras-primas da engenharia. Outros parecerão um labirinto digno da Matrix.
A tentação será adicionar "apenas mais um IF" ou "mais um GO TO" para resolver rapidamente um incidente. Resista.
Sempre que possível:
extraia responsabilidades para novos módulos;
elimine duplicações;
substitua fluxos confusos por estruturas claras;
escreva nomes compreensíveis;
documente regras de negócio;
mantenha testes atualizados.
Cada pequena melhoria reduz um pouco o emaranhado do espaguete e facilita o trabalho do próximo desenvolvedor.
Conclusão — Saindo do Prato de Espaguete da Matrix
No final da trilogia Matrix, Neo percebe que compreender a estrutura da Matrix é mais poderoso do que simplesmente reagir a ela.
Na Engenharia de Software, acontece exatamente o mesmo.
O maior problema do Spaghetti Code não é ser feio.
É transformar cada alteração em uma aventura imprevisível.
Em sistemas COBOL responsáveis por processar milhões de transações financeiras, isso significa mais tempo de manutenção, maior risco de incidentes, consumo adicional de CPU, testes mais demorados e equipes receosas de evoluir o software.
No universo Bellacosa Mainframe existe uma máxima que todo Programador COBOL Padawan deveria guardar:
"Cada
GO TOdesnecessário é mais um corredor dentro da Matrix. Cada módulo bem organizado é uma porta de saída."
O objetivo não é escrever o código mais inteligente.
É escrever o código que outro programador — talvez você mesmo daqui a dez anos — consiga entender sem precisar da ajuda do Oráculo.
Porque o verdadeiro Escolhido não é aquele que cria o maior labirinto.
É aquele que sabe construir o caminho mais simples até a solução.
Sem comentários:
Enviar um comentário