 |
| Bellacosa Mainframe e o monstro da divida tecnica |
☕💣 DÍVIDA TÉCNICA: O MONSTRO INVISÍVEL QUE ESTÁ COMENDO O SEU COBOL DESDE O SÉCULO PASSADO
"O sistema funciona perfeitamente. Só ninguém sabe como."
Se você trabalha com Mainframe há algum tempo, provavelmente já ouviu frases como:
"Não mexe nisso que funciona."
"Esse programa está em produção há 20 anos."
"Só o João sabe alterar esse módulo."
"Depois a gente documenta."
"Precisamos entregar hoje."
Parabéns.
Você acabou de encontrar alguns dos maiores sintomas de uma das doenças mais comuns da tecnologia moderna:
A Dívida Técnica.
E não, ela não acontece apenas em Java, Python ou aplicações web modernas.
Na verdade, muitos dos maiores casos de dívida técnica do planeta estão rodando neste exato momento em sistemas COBOL responsáveis por bancos, seguradoras, governos, companhias aéreas e bolsas de valores.
Vamos entender o que é, como identificar, controlar e principalmente como sobreviver a ela.
O QUE É DÍVIDA TÉCNICA?
A definição mais simples é:
Dívida Técnica é o custo futuro gerado quando escolhemos uma solução rápida hoje em vez da melhor solução possível.
Imagine que você recebeu uma demanda urgente.
O gerente aparece correndo:
"Precisamos colocar essa alteração em produção amanhã."
Você sabe que o correto seria:
revisar a arquitetura;
atualizar documentação;
criar casos de teste;
revisar impactos;
atualizar fluxogramas.
Mas o prazo não permite.
Então você faz um ajuste rápido.
Entrega.
Todo mundo feliz.
Até que seis meses depois alguém precisa alterar novamente aquele trecho.
Agora ninguém entende mais nada.
A dívida venceu.
E os juros começaram a ser cobrados.
A ANALOGIA COM O CARTÃO DE CRÉDITO
A comparação mais famosa é com uma dívida financeira.
Quando você compra algo parcelado:
Você ganha agora.
Mas paga depois.
Na dívida técnica acontece exatamente o mesmo.
Você ganha:
velocidade;
prazo;
entrega rápida.
Mas paga depois com:
bugs;
retrabalho;
manutenção cara;
incidentes de produção.
Quanto mais tempo passa, maiores ficam os juros.
O COBOL NÃO CRIA DÍVIDA TÉCNICA
Essa é uma das maiores injustiças da informática.
Muitos dizem:
"Cobol é dívida técnica."
Errado.
COBOL não é dívida técnica.
COBOL mal mantido é dívida técnica.
Existem programas COBOL escritos há 30 anos que continuam:
legíveis;
documentados;
organizados;
eficientes.
E existem aplicações modernas escritas há seis meses que já parecem um filme de terror.
A linguagem não é o problema.
A disciplina é.
COMO A DÍVIDA TÉCNICA NASCE
Ela normalmente surge de quatro formas.
1. Pressão por prazo
O caso mais comum.
"Entrega primeiro."
"Arruma depois."
O problema é que o depois quase nunca chega.
2. Falta de documentação
O desenvolvedor conhece tudo.
Então ele pensa:
"Não preciso documentar."
Dois anos depois ele muda de empresa.
Agora ninguém entende o programa.
3. Correções emergenciais
Produção caiu.
Cliente está ligando.
Diretoria está nervosa.
O objetivo vira apenas:
"Faça voltar."
Nesse momento quase ninguém pensa em qualidade.
4. Sistemas legados
Bibliotecas antigas.
COPYBOOKs herdados.
Macros esquecidas.
JCLs copiados durante décadas.
Tudo isso acumula dívida.
EXEMPLO REAL DE DÍVIDA TÉCNICA EM COBOL
Imagine um cálculo de desconto.
Versão original:
IF CLIENTE-VIP
COMPUTE DESCONTO = VALOR * 0.15
END-IF
Simples.
Legível.
Agora passam dez anos.
Novas regras surgem.
Resultado:
IF CLIENTE-TIPO = 'A'
...
ELSE
IF CLIENTE-TIPO = 'B'
...
ELSE
IF CLIENTE-TIPO = 'C'
...
Mais tarde:
IF CLIENTE-TIPO = 'A'
...
ELSE
IF CLIENTE-TIPO = 'B'
...
ELSE
IF CLIENTE-TIPO = 'C'
...
ELSE
IF REGIAO = 'S'
...
Depois de centenas de mudanças:
Ninguém sabe mais como o cálculo funciona.
O programa funciona.
Mas ninguém entende.
Isso é dívida técnica.
OS SINTOMAS MAIS PERIGOSOS
Se você encontrar estes sinais, ligue o alerta.
Programas gigantes
Mais de 10.000 linhas.
COPYBOOKs duplicados
A mesma estrutura em vários lugares.
JCLs clonados
Mudam apenas o nome do JOB.
Falta de comentários
Tudo depende da memória dos analistas.
Testes manuais
Ninguém consegue validar rapidamente.
Dependência de uma pessoa
"O Carlos sabe."
Quando você ouve isso, existe dívida técnica.
O EFEITO JUROS COMPOSTOS
Aqui está a parte assustadora.
Dívida técnica cresce de forma parecida com juros compostos.
Um bug gera:
remendo;
novo remendo;
ajuste do remendo;
correção da correção.
Depois de alguns anos ninguém consegue alterar sem medo.
O custo explode.
COMO MAPEAR DÍVIDA TÉCNICA
Primeiro passo:
Pare de adivinhar.
Crie um inventário.
Faça uma planilha simples.
Colunas:
Sistema
Programa
Problema
Impacto
Complexidade
Prioridade
Exemplo:
| Programa | Problema | Impacto |
|---|---|---|
| COBCLI01 | Sem documentação | Alto |
| COBFAT02 | 12.000 linhas | Alto |
| COBPAG03 | Sem testes | Médio |
Agora a dívida virou algo visível.
MÉTRICAS IMPORTANTES
Um programador júnior deve aprender a medir.
Algumas métricas úteis:
Número de ABENDs
Se cresce continuamente:
há algo errado.
Tempo de correção
Quanto tempo leva para corrigir um incidente?
Quanto maior, maior a dívida.
Quantidade de módulos sem documentação
Métrica simples e poderosa.
Cobertura de testes
Quanto mais baixa, maior o risco.
FERRAMENTAS ÚTEIS NO MAINFRAME
Muitos iniciantes acham que Mainframe não possui ferramentas modernas.
Possui.
E muitas.
IBM Application Discovery
Mapeia dependências.
Excelente para sistemas gigantes.
IBM ADDI
Application Discovery and Delivery Intelligence.
Mostra relacionamentos entre:
COBOL
JCL
DB2
CICS
IBM Debug Tool
Ajuda a entender comportamento de programas complexos.
IBM Fault Analyzer
Investiga ABENDs.
IBM File Manager
Analisa arquivos rapidamente.
IBM Dependency Based Build
Automação moderna para pipelines Mainframe.
COMO REDUZIR A DÍVIDA
Agora vem a parte prática.
Passo 1 – Pare de criar dívida nova
Antes de pagar a antiga.
Evite criar mais.
Parece óbvio.
Mas é onde tudo começa.
Passo 2 – Refatore pequenos trechos
Não tente reescrever tudo.
Ataque pequenas áreas.
Exemplo:
nomes ruins;
IFs excessivos;
parágrafos gigantes.
Passo 3 – Documente enquanto aprende
Cada descoberta vira documentação.
Não espere um projeto oficial.
Passo 4 – Automatize testes
Mesmo testes simples ajudam.
Menos medo de alterar.
Mais velocidade.
Passo 5 – Padronize
Defina padrões.
Por exemplo:
nomenclatura;
comentários;
estrutura de programas;
organização de COPYBOOKs.
O ERRO MAIS COMUM DOS JUNIORES
Achar que refatorar significa reescrever tudo.
Não.
Refatoração significa melhorar sem alterar comportamento.
Você limpa.
Organiza.
Simplifica.
Sem mudar resultado.
O SEGREDO DOS ANALISTAS SENIORES
Muitos iniciantes acreditam que profissionais experientes sabem tudo.
Não sabem.
A diferença é que eles:
documentam mais;
investigam melhor;
evitam atalhos perigosos;
controlam a dívida técnica.
O conhecimento não está apenas no código.
Está na disciplina.
EASTER EGG DOS MAINFRAMEIROS
Se encontrar um comentário parecido com:
* NÃO REMOVER
* FUNCIONA ASSIM DESDE 1994
Você provavelmente encontrou um artefato arqueológico corporativo.
Trate com respeito.
Mas investigue.
Porque muitas vezes ele esconde uma dívida técnica histórica.
A REGRA DOS 5 MINUTOS
Uma dica poderosa.
Se você gastou cinco minutos para entender algo complicado:
documente.
O próximo desenvolvedor agradecerá.
E talvez esse próximo desenvolvedor seja você daqui a seis meses.
COMO EVOLUIR NA CARREIRA ATRAVÉS DA DÍVIDA TÉCNICA
Os melhores profissionais não são os que criam mais código.
São os que reduzem complexidade.
Quando você aprende a:
mapear problemas;
documentar;
simplificar;
automatizar;
refatorar;
você deixa de ser apenas um programador.
Você passa a ser um engenheiro de software.
CONCLUSÃO
Dívida técnica não é um bug.
Não é um ABEND.
Não é um programa COBOL antigo.
Ela é o resultado de decisões acumuladas ao longo do tempo.
Algumas são necessárias.
Outras são perigosas.
O segredo não é eliminar toda dívida técnica.
Isso é impossível.
O segredo é conhecê-la, monitorá-la e pagá-la antes que ela assuma o controle do sistema.
Porque, no final das contas, o verdadeiro problema não é aquele programa COBOL de 1987.
O problema é ninguém mais entender por que ele ainda funciona.
E quando esse dia chega...
o próximo chamado de produção costuma acontecer às 03:17 da manhã de um domingo.
Aproveite e conheça BACKLOG
https://eljefemidnightlunch.blogspot.com/2025/01/backlog-o-arquivo-secreto-que-separa-um.html
