 |
| Bellacosa Mainframe e o cargo cult programming rules |
☕ Um Café no Bellacosa Mainframe
Cargo Cult Programming Rules sem Mistérios
Quando um Programador COBOL Descobriu que Copiar Código na Matrix Era Como Tomar a Pílula Vermelha... Sem Entender o Que Ela Fazia
"Na Matrix, copiar um comando sem compreendê-lo é como repetir uma senha mágica esperando que o universo obedeça. Às vezes funciona. Quase sempre cobra um preço."
Prólogo — O Mistério da Linha que Ninguém Ousava Apagar
A Nebuchadnezzar acabara de retornar de mais uma missão.
No centro de Zion existia um enorme sistema responsável por controlar energia, comunicações e defesa.
Neo recebeu um chamado.
Apenas uma linha precisava ser alterada.
Parecia simples.
Ao abrir o código COBOL, encontrou algo curioso.
MOVE ZERO TO WS-CONTROLE.
Logo abaixo havia um comentário.
* NÃO REMOVER
* FUNCIONA ASSIM HÁ 23 ANOS
Neo perguntou:
— Morpheus, por que essa linha existe?
Morpheus respondeu:
— Ninguém sabe.
— Então por que ela continua aí?
— Porque um programador a copiou de outro programa.
Neo abriu outro módulo.
A mesma linha.
Depois outro.
Mais um.
Cinquenta programas.
A mesma instrução.
Ninguém sabia explicar.
O Oráculo apareceu silenciosamente.
— Bem-vindo ao Cargo Cult Programming.
O que é Cargo Cult Programming?
Cargo Cult Programming é um antipadrão onde desenvolvedores copiam código, configurações, comandos ou arquiteturas sem compreender por que aquilo existe ou qual problema realmente resolve.
Em outras palavras:
É repetir uma solução esperando obter o mesmo resultado, mesmo sem entender a lógica por trás dela.
É um comportamento extremamente comum.
Especialmente na era da Internet.
A verdadeira origem do termo
O nome não nasceu na computação.
Nasceu na antropologia.
Durante a Segunda Guerra Mundial, diversas ilhas do Pacífico receberam bases militares americanas.
Os aviões chegavam carregados de alimentos, remédios, roupas e equipamentos — o cargo.
Quando a guerra terminou, os militares partiram.
Os aviões deixaram de chegar.
Alguns habitantes observaram que:
havia pistas de pouso;
torres de controle;
soldados usando fones;
sinalizadores.
Sem compreender a logística, a indústria ou a tecnologia envolvidas, reconstruíram pistas de madeira, antenas de bambu e fones feitos de coco, acreditando que, ao reproduzir aqueles elementos, os aviões voltariam.
Os aviões nunca voltaram.
Eles copiaram a aparência.
Não compreenderam a causa.
Richard Feynman popularizou o conceito
Em 1974, o físico Richard Feynman, prêmio Nobel, utilizou essa história em seu famoso discurso:
Cargo Cult Science
Ele criticava pesquisas que imitavam a aparência da ciência, mas ignoravam seu método.
A Engenharia de Software adotou exatamente a mesma metáfora.
Matrix explica perfeitamente
Imagine que Neo vê Trinity digitando rapidamente.
Ela executa alguns comandos.
O sistema volta a funcionar.
Neo anota tudo.
Dias depois surge outro problema.
Sem entender absolutamente nada, ele digita exatamente os mesmos comandos.
Por sorte...
funciona.
Então conclui:
"Esse é o procedimento."
Na terceira vez...
o sistema inteiro para.
O problema nunca foi o comando.
Era o contexto.
O Cargo Cult no mundo COBOL
Esse comportamento existe desde os cartões perfurados.
Imagine um programador iniciante.
Ele encontra um programa funcionando perfeitamente.
Então pensa:
"Vou copiar este trecho."
Sem entender:
por que existe;
quais premissas ele assume;
quais dados espera receber;
quais efeitos colaterais produz.
O código passa a viver uma segunda vida.
Depois uma terceira.
Depois dezenas.
Um exemplo clássico
Imagine este trecho.
IF SQLCODE NOT = ZERO
GO TO ERRO.
END-IF
O iniciante copia para outro programa.
Mas naquele programa:
SQLCODE nunca foi inicializado.
Não existe EXEC SQL.
Nem mesmo há acesso ao Db2.
O teste permanece.
Não faz sentido.
Mas ninguém percebe.
Outro exemplo
Durante anos muitos programadores copiavam:
REGION=0M
Pergunta.
Era realmente necessário?
Muitos não sabiam.
Apenas copiaram.
Mais um exemplo
Encontramos frequentemente programas contendo:
MOVE SPACES TO WS-TABELA.
Logo depois:
INITIALIZE WS-TABELA.
O segundo comando já faz o trabalho.
Mas alguém copiou de outro programa.
E assim permanece há vinte anos.
Como nasce o Cargo Cult?
Normalmente acontece em quatro etapas.
Etapa 1
Existe uma solução correta.
Etapa 2
Alguém copia.
Etapa 3
Outras pessoas copiam a cópia.
Etapa 4
Ninguém mais conhece o motivo original.
Matrix Reloaded
O Arquiteto mostra milhares de versões anteriores da Matrix.
Cada versão acumulou decisões antigas.
Algumas ainda existiam.
Mas ninguém lembrava por quê.
Isso é exatamente o que acontece em sistemas legados.
O efeito psicológico
Existe uma explicação interessante.
Nosso cérebro prefere:
imitar
antes de
compreender.
É assim que aprendemos a falar.
A andar.
A escrever.
Na programação isso também acontece.
O problema é parar na imitação.
O Programador COBOL Padawan
Todo Padawan faz isso.
E isso não é necessariamente ruim.
Copiar exemplos é uma excelente forma de aprender.
O erro começa quando:
copiar
substitui
entender.
O Agente Smith adora isso
Porque cada linha copiada sem entendimento cria:
mais complexidade.
Mais dependência.
Mais bugs.
Mais medo.
Um exemplo inspirado na Matrix
Neo encontra um procedimento.
PASSO 1
Executar JOB LIMPA01
PASSO 2
Executar SORT02
PASSO 3
Executar FIX03
Pergunta.
Por quê?
Resposta.
"Nunca perguntamos."
Esse é o verdadeiro problema.
Cargo Cult e Inteligência Artificial
Este assunto ficou ainda mais importante.
Hoje muitos desenvolvedores fazem:
Pergunta ao ChatGPT.
Recebe código.
Copia.
Compila.
Entrega.
Sem compreender.
Isso também pode ser Cargo Cult Programming.
A IA acelera muito o desenvolvimento.
Mas não substitui entendimento.
Ela entrega possibilidades.
O engenheiro decide.
Como evitar isso?
Leia antes de copiar
Entenda cada linha.
Pergunte
Por que isso existe?
Faça experimentos
Remova.
Teste.
Observe.
Leia documentação
Ela normalmente explica o motivo.
Use Debug
Ver código executando ensina mais que copiar.
Atenção!
Existe uma enorme diferença entre:
Reutilização
e
Cargo Cult.
Reutilização
Entende.
Valida.
Adapta.
Documenta.
Cargo Cult
Copia.
Compila.
Espera funcionar.
O custo invisível
Código copiado gera:
duplicação.
Bugs.
Regras inconsistentes.
Arquitetura confusa.
Dependências desnecessárias.
O Mainframe sofre com isso?
Muito.
Imagine um banco.
Existem:
4.000 programas COBOL.
Um tratamento de erro foi copiado.
Depois outro.
Depois outro.
Após vinte anos.
Existem:
327 versões diferentes.
Todas parecidas.
Nenhuma igual.
Um exemplo de SQL
Encontramos frequentemente:
SELECT *
Pergunta.
Era necessário?
Talvez.
Talvez não.
Mas foi copiado.
Outro exemplo
Tratamentos como:
IF WS-FLAG = "S"
Pergunta.
Por que "S"?
Ninguém sabe.
Talvez fosse:
Sim.
Seguro.
Sucesso.
Saldo.
Supervisor.
Sistema.
Ninguém documentou.
Os perigos
Segurança
Código copiado pode conter vulnerabilidades.
Performance
Soluções antigas permanecem.
Bugs
Premissas diferentes.
Arquitetura
Perde consistência.
Manutenção
Ninguém entende.
Curiosidade
Grandes incidentes de software já ocorreram porque equipes copiaram configurações de produção para homologação — ou vice-versa — sem compreender as diferenças de ambiente.
O papel da documentação
Documentação explica:
o quê
e principalmente:
por quê.
Sem esse "por quê", o próximo programador pode transformar uma boa prática em um ritual vazio.
O papel do mentor
Um bom mentor nunca responde apenas:
"Faça assim."
Ele responde:
"Faça assim porque..."
Essa segunda parte é a que forma arquitetos.
Matrix e a Pílula Vermelha
Tomar a pílula vermelha não era repetir um ritual.
Era compreender a realidade.
Na Engenharia de Software acontece igual.
Copiar código é a pílula azul.
Entender arquitetura é a vermelha.
Curiosidades
Empresas maduras incentivam:
Code Review.
Pair Programming.
Arquitetura documentada.
ADRs.
Design Reviews.
Sessões técnicas.
O objetivo é justamente reduzir Cargo Cult.
Aplicabilidade
Esse antipadrão aparece em:
COBOL.
Java.
Python.
C.
C++.
JavaScript.
SQL.
Kubernetes.
Docker.
Terraform.
Cloud.
DevOps.
Nenhuma linguagem escapa.
Erros clássicos
Copiar código do Stack Overflow sem análise.
Copiar parâmetros de compilação sem conhecer seus efeitos.
Duplicar JCLs sem revisar DDNAMEs.
Repetir SQL sem avaliar índices.
Usar frameworks apenas porque "todo mundo usa".
Copiar prompts de IA sem verificar o resultado.
Boas práticas
Entenda antes de reutilizar.
Faça perguntas constantemente.
Documente decisões importantes.
Prefira bibliotecas reutilizáveis a copiar blocos inteiros.
Escreva testes que validem o comportamento.
Revise código em equipe.
O ensinamento do Oráculo
O Oráculo entrega um pequeno espelho para Neo.
Ele olha.
Não vê código.
Vê perguntas.
"Por que essa linha existe?"
"Quem escreveu isso?"
"Qual problema ela resolve?"
"Ainda faz sentido?"
Essas quatro perguntas eliminam metade do Cargo Cult existente em qualquer empresa.
Lições para um Programador COBOL Padawan
Durante sua carreira você encontrará programas escritos há trinta ou quarenta anos. Muitos conterão soluções brilhantes. Outros carregarão decisões que fizeram sentido em um hardware específico, em uma versão antiga do compilador ou diante de uma regra de negócio que já não existe.
Não assuma que tudo deve ser preservado nem que tudo deve ser removido. Investigue. Leia os comentários, converse com especialistas, depure o código, consulte a documentação e compreenda o contexto.
Quando utilizar exemplos da Internet, de colegas ou até de uma Inteligência Artificial, faça o mesmo. O objetivo não é apenas produzir código que compile, mas construir soluções que você consiga explicar para outra pessoa.
Conclusão — O Código Não é Magia, É Conhecimento
No final da trilogia Matrix, Neo percebe que a realidade não é governada por feitiços, mas por regras que podem ser compreendidas.
Na Engenharia de Software, o Cargo Cult Programming nasce quando tratamos código como se fosse um feitiço:
"Copie esta função."
"Cole este comando."
"Use esse parâmetro."
"Nunca remova essa linha."
Sem compreender os motivos.
Para um Programador COBOL, essa armadilha é especialmente perigosa. Sistemas legados concentram décadas de conhecimento de negócio, integrações complexas e otimizações específicas. Copiar trechos sem entender seu propósito pode introduzir erros silenciosos, aumentar a dívida técnica e dificultar futuras manutenções.
No universo Bellacosa Mainframe existe uma máxima que todo Padawan deveria levar consigo:
"Um código copiado resolve um problema por alguns minutos. Um código compreendido resolve problemas por toda a carreira."
E essa é a verdadeira diferença entre alguém que apenas sobrevive dentro da Matrix e alguém que realmente aprende a enxergar o código que existe por trás dela.
