 |
| Bellacosa Mainframe e a lava flow rules |
☕ Um Café no Bellacosa Mainframe
Lava Flow Rules sem Mistérios
Quando um Programador COBOL Descobriu que a Matrix Estava Coberta por Fluxos de Lava Digital que Ninguém Tinha Coragem de Remover
"O maior perigo dos sistemas legados nem sempre é o código que executa. Muitas vezes é o código que ninguém ousa apagar."
Prólogo — A Sala Proibida da Matrix
Depois de inúmeras batalhas contra o Agente Smith, Neo acreditava conhecer praticamente toda a Matrix.
Foi então que o Arquiteto abriu uma porta que nunca havia sido mostrada.
Atrás dela existia um gigantesco datacenter.
Milhares de programas.
Milhões de linhas de código.
No centro da sala havia uma placa metálica.
NÃO MODIFICAR
Neo perguntou:
— O que existe aí?
O Arquiteto respondeu:
— Não sabemos exatamente.
Neo estranhou.
— Como assim?
— Esse código foi escrito antes mesmo da sexta versão da Matrix.
— Ele ainda é usado?
O Arquiteto permaneceu em silêncio.
O Oráculo apareceu.
Olhou para Neo.
Depois para o enorme programa.
Sorriu.
— Talvez sim.
Talvez não.
Neo perguntou:
— Então por que ninguém remove?
O Oráculo respondeu:
"Porque ninguém quer descobrir a resposta em plena produção."
Bem-vindo ao Lava Flow.
O que é Lava Flow?
Lava Flow é um antipadrão de software onde partes antigas do sistema permanecem indefinidamente porque ninguém sabe se ainda são utilizadas.
São blocos de código que:
ninguém compreende completamente;
aparentemente não possuem função;
não aparecem na documentação;
mas continuam existindo por medo de removê-los.
Eles se tornam verdadeiros fósseis digitais.
A origem do nome
O termo surgiu no livro clássico AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, publicado em 1998 por William J. Brown, Raphael Malveau, Hays McCormick III e Thomas Mowbray.
A metáfora é brilhante.
Quando um vulcão entra em erupção, a lava escorre livremente.
Depois de esfriar...
ela endurece.
Com o tempo ninguém consegue mais movê-la.
Mesmo que atrapalhe a construção de estradas ou cidades.
No software acontece exatamente isso.
Uma decisão antiga endurece.
Ninguém mais consegue removê-la.
Matrix explica perfeitamente
Imagine que cada versão da Matrix deixa pequenos trechos de código esquecidos.
Programas antigos.
Rotinas obsoletas.
Protocolos desativados.
Funções nunca mais chamadas.
Mas ninguém ousa apagar.
Porque talvez...
alguma parte escondida ainda dependa delas.
Como nasce um Lava Flow?
Quase sempre começa assim.
Um projeto urgente.
Uma solução temporária.
O desenvolvedor comenta:
"Depois limpamos."
Mas o projeto termina.
A equipe muda.
O conhecimento desaparece.
O código continua.
O COBOL conhece muito bem esse fenômeno
Imagine um programa escrito em 1989.
Em determinado momento existia uma regra para calcular uma antiga taxa bancária.
Essa taxa deixou de existir em 1998.
Mas a rotina continua lá.
Em 2004 alguém perguntou:
— Podemos apagar?
Resposta:
— Melhor não...
Vai que algum lote ainda usa.
Em 2012 outra pessoa perguntou.
Mesma resposta.
Em 2026...
A rotina continua.
Um exemplo clássico
Imagine um trecho como este.
IF WS-TIPO = "X"
PERFORM CALCULA-TAXA-ESPECIAL
END-IF
Pergunta.
Existe algum cliente com tipo X?
Ninguém sabe.
A consulta nunca foi feita.
Então o código permanece.
Outro exemplo COBOL
Você encontra:
PERFORM ROTINA-LEGADA.
Procura quem chama essa rotina.
Descobre que:
ninguém.
Mas ninguém remove.
Porque talvez exista:
um JCL antigo;
um programa batch esquecido;
uma PROC histórica;
um processo anual.
Matrix Reloaded
Lembra dos programas exilados?
Merovíngio abriga programas antigos que deveriam ter sido removidos.
Eles continuam existindo porque encontraram maneiras de sobreviver.
Esses personagens representam perfeitamente o conceito de Lava Flow.
São códigos que perderam sua função original, mas continuam ocupando espaço na Matrix.
O efeito psicológico
Existe uma frase muito conhecida em equipes de manutenção.
"Se está funcionando, não mexa."
Ela protege a estabilidade.
Mas também pode proteger código morto.
O medo da mudança faz com que partes inteiras do sistema permaneçam congeladas por décadas.
O Programador COBOL Padawan
Você abre um programa.
Encontra:
IF WS-FLAG-1987 = "S"
Pergunta ao analista mais experiente.
— O que significa?
Resposta.
— Acho que tem relação com um produto antigo.
"Acho."
Essa palavra deveria acender um alerta.
O Agente Smith adora Lava Flow
Porque código morto aumenta:
complexidade;
tempo de leitura;
dificuldade de testes;
risco de manutenção.
Quanto mais difícil compreender o sistema, mais fácil ele se torna de dominar.
Um exemplo inspirado na Matrix
Neo encontra uma porta.
Ela não leva a lugar nenhum.
Pergunta ao Chaveiro.
— Posso removê-la?
O Chaveiro responde.
— Talvez.
Neo insiste.
— Alguém usa?
O Chaveiro sorri.
— Faz muito tempo que ninguém passa por ela...
Mas ninguém quer ser o primeiro a descobrir.
Como reconhecer Lava Flow?
Alguns sinais são clássicos.
Comentários antigos
TEMPORÁRIO
REMOVER DEPOIS
E o comentário tem quinze anos.
Código nunca executado
Cobertura de testes mostra zero chamadas.
Variáveis sem uso
Declaradas.
Nunca lidas.
COPYBOOKs esquecidos
Presentes.
Jamais referenciados.
JCLs históricos
Executados pela última vez em 2014.
O custo invisível
Cada novo desenvolvedor precisa entender:
o código ativo
o código morto.
Mesmo que metade nunca execute.
O impacto no Mainframe
Mainframes corporativos costumam preservar compatibilidade por décadas.
Isso é excelente para o negócio.
Mas também significa que:
programas antigos sobrevivem;
interfaces antigas permanecem;
layouts históricos continuam disponíveis.
Nem tudo pode ser removido imediatamente.
Atenção!
Lava Flow não significa simplesmente "código antigo".
Código antigo pode ser extremamente importante.
O problema é:
código antigo
sem propósito conhecido.
A diferença
Legado
Ainda possui função.
Lava Flow
Ninguém sabe se possui função.
Curiosidade
Diversos sistemas bancários ainda mantêm rotinas para formatos de arquivos que não são utilizados há muitos anos, apenas porque existe a possibilidade de algum cliente institucional ainda depender deles em um processamento específico.
Ferramentas ajudam
Hoje é possível descobrir muito mais do que antigamente.
Ferramentas como:
IBM Application Discovery and Delivery Intelligence (ADDI);
IBM Developer for z/OS;
IBM COBOL Check;
SonarQube;
Enterprise Analyzer;
permitem identificar:
programas sem referências;
COPYBOOKs não utilizados;
dependências reais;
fluxo de chamadas;
cobertura de execução.
Elas reduzem significativamente o medo de remover código.
Como evitar?
Descoberta arquitetural
Conheça dependências reais.
Testes automatizados
Eles fornecem confiança.
Monitoramento
Descubra quem realmente utiliza cada componente.
Refatoração contínua
Pequenas limpezas são mais seguras do que grandes reescritas.
Documentação viva
Explique por que algo permanece.
Revisões periódicas
Reserve tempo para eliminar o que perdeu utilidade.
O perigo da limpeza precipitada
O extremo oposto também é perigoso.
Imagine remover uma rotina porque "parece inútil".
Na madrugada do último dia útil do ano...
ela é executada pelo fechamento contábil.
Resultado:
ABEND.
Incidente crítico.
Por isso remover exige evidências.
Nunca intuição.
Matrix e os Programas Exilados
O Merovíngio colecionava programas antigos.
Eles não tinham mais função oficial.
Mesmo assim continuavam vivos.
Esses personagens representam exatamente os componentes esquecidos que permanecem escondidos em sistemas corporativos.
Nem todos causam problemas.
Mas todos aumentam a complexidade.
O papel da IA
Ferramentas baseadas em IA podem:
localizar código aparentemente morto;
resumir módulos antigos;
mapear dependências;
identificar duplicações;
sugerir candidatos à remoção.
Entretanto, a decisão final continua sendo humana.
Especialmente em ambientes críticos.
Os riscos
Complexidade crescente
Mais código para entender.
Testes maiores
Mais cenários.
Custos
Mais manutenção.
Bugs
Mudanças evitadas por medo.
Segurança
Bibliotecas antigas podem permanecer vulneráveis.
Conhecimento perdido
Ninguém sabe mais o propósito original.
Erros clássicos
Nunca revisar código legado.
Confundir estabilidade com imobilidade.
Manter funcionalidades desativadas indefinidamente.
Não registrar decisões arquiteturais.
Ignorar ferramentas de análise de dependência.
Boas práticas
Mantenha inventário de componentes.
Monitore utilização real.
Elimine código comprovadamente morto.
Escreva testes antes de remover.
Documente exceções de negócio.
Faça limpezas graduais.
Aplicabilidade
Lava Flow aparece em praticamente qualquer tecnologia:
COBOL;
PL/I;
Java;
C#;
Python;
C++;
APIs;
microsserviços;
aplicações em nuvem;
sistemas embarcados.
Quanto maior a vida útil do software, maior a chance desse antipadrão surgir.
O ensinamento do Oráculo
O Oráculo leva Neo até um antigo rio de lava endurecida.
Ela pergunta:
— O que você vê?
Neo responde.
— Pedra.
Ela toca a superfície.
Debaixo dela ainda existe calor.
Então diz:
"No software acontece igual. O código pode parecer morto, mas ainda pode sustentar parte da montanha."
Antes de remover.
Investigue.
Lições para um Programador COBOL Padawan
Ao iniciar sua carreira no universo IBM Z, você encontrará programas com décadas de existência. Alguns conterão comentários escritos por pessoas que já se aposentaram. Outros farão referência a produtos, moedas, legislações e tecnologias que nem existem mais.
Não assuma que tudo isso é lixo.
Também não assuma que tudo é indispensável.
Seu papel é agir como um arqueólogo digital:
entender o contexto;
mapear dependências;
conversar com especialistas;
validar com testes;
registrar descobertas;
remover apenas aquilo cuja inutilidade esteja comprovada.
Essa disciplina preserva a estabilidade do negócio e, ao mesmo tempo, impede que a lama endurecida continue crescendo indefinidamente.
Conclusão — Nem Toda Rocha Deve Permanecer Para Sempre
Na Matrix, programas antigos podiam sobreviver escondidos entre versões sucessivas da simulação. Alguns ainda tinham propósito. Outros apenas ocupavam espaço.
Nos sistemas corporativos acontece exatamente o mesmo.
O Lava Flow representa decisões antigas que endureceram com o tempo. Elas deixaram de ser questionadas porque questioná-las parece perigoso.
Mas engenharia madura não significa apagar tudo.
Significa compreender antes de agir.
Para um Programador COBOL, essa é uma das maiores demonstrações de responsabilidade profissional. Cada remoção deve ser sustentada por evidências, testes, monitoramento e conhecimento do negócio.
No universo Bellacosa Mainframe existe uma máxima que o próprio Oráculo aprovaria:
"O código mais perigoso não é o antigo. É aquele cujo propósito ninguém mais consegue explicar."
Porque, assim como na Matrix, o verdadeiro desafio não é destruir o passado.
É descobrir quais partes dele ainda sustentam o presente e quais já podem, finalmente, descansar.
Sem comentários:
Enviar um comentário