 |
| Bellacosa Mainframe e as technical debt rules |
☕ Um Café no Bellacosa Mainframe
Technical Debt Rules sem Mistérios
Quando um Programador COBOL Descobriu que Cada Atalho Criava um Agente Smith Dentro do Sistema
"Infelizmente, ninguém pode explicar o que é a Dívida Técnica. Você precisa vê-la por si mesmo." — inspirado no universo de Matrix
Bem-vindo à Matrix do Desenvolvimento
Imagine que você acorda em uma sala escura.
Na sua frente existe um monitor verde.
Linhas de caracteres descem como chuva.
Um homem de óculos escuros aproxima-se.
Não é Morpheus.
É o Analista de Sistemas mais antigo da empresa.
Ele coloca duas fitas magnéticas sobre a mesa.
Uma vermelha.
Outra azul.
— A azul compila hoje.
— A vermelha exige refatoração, testes, documentação e arquitetura.
Você pergunta:
— Qual delas devo escolher?
Ele sorri.
— A azul entrega o projeto este mês.
— A vermelha salva os próximos dez anos.
Naquele instante você entende que toda equipe de desenvolvimento vive diariamente essa escolha.
Esse é o universo da Technical Debt, ou Dívida Técnica, um dos conceitos mais importantes — e mais mal compreendidos — da Engenharia de Software.
Para quem trabalha com COBOL, CICS, Db2, JCL e sistemas legados, entender a Dívida Técnica é quase tão importante quanto saber interpretar um ABEND. Ela explica por que alguns sistemas envelhecem com dignidade enquanto outros se tornam um labirinto impossível de manter.
O que é Technical Debt?
Technical Debt é o custo futuro provocado por decisões técnicas tomadas para ganhar velocidade no presente.
Em outras palavras:
É quando você economiza tempo hoje emprestando tempo do seu próprio futuro.
Assim como um empréstimo bancário, a dívida técnica pode ser útil quando administrada conscientemente.
O problema não é contrair uma dívida.
O problema é esquecer que ela existe.
A origem do termo
O termo Technical Debt foi criado em 1992 por Ward Cunningham, um dos autores do Manifesto Ágil e criador do primeiro Wiki da história.
Ward percebeu que muitos gestores entendiam dinheiro, juros e empréstimos, mas tinham dificuldade para compreender problemas de arquitetura de software.
Então fez uma analogia brilhante.
Ele disse:
"Entregar um software antes de terminar sua arquitetura é como fazer um empréstimo. Pode ser uma boa decisão, desde que você pague rapidamente."
O problema aparece quando os juros começam.
E em software...
...os juros aparecem em forma de:
bugs
retrabalho
lentidão
dificuldades para alterar regras
aumento do tempo de testes
aumento de incidentes
Matrix explica melhor que muitos livros
Imagine que cada linha de código seja parte da Matrix.
Quando tudo é desenvolvido corretamente...
a simulação permanece estável.
Mas sempre existe alguém dizendo:
"Depois a gente arruma."
Esse "depois" nunca chega.
Cada pequeno atalho cria pequenas distorções.
No começo parecem insignificantes.
Depois surgem pequenos defeitos.
Mais tarde aparecem exceções.
Finalmente...
a Matrix inteira começa a produzir Agentes Smith.
Quem são os Agentes Smith?
No mundo do software, os Agentes Smith representam problemas que surgem continuamente.
Cada vez que um desenvolvedor resolve um bug rapidamente sem corrigir sua causa...
nasce um novo Smith.
Cada IF duplicado...
mais um Smith.
Cada variável mal nomeada...
outro Smith.
Cada programa COBOL de cinquenta mil linhas...
centenas deles.
Eles continuam se multiplicando até dominar todo o sistema.
Um exemplo COBOL
Imagine este código:
IF TIPO = "A"
MOVE 15 TO DESCONTO
END-IF
Alguns meses depois.
Nova regra.
IF TIPO = "A"
MOVE 20 TO DESCONTO
END-IF
Mais tarde.
Outro programador.
IF CLIENTE-PREMIUM
MOVE 25 TO DESCONTO
END-IF
Depois.
Outro módulo.
Mesmo código.
Depois outro.
E outro.
Agora existem quinze versões diferentes da mesma regra.
Toda alteração exige procurar manualmente.
Esse é um clássico exemplo de dívida técnica.
O que gera Technical Debt?
Pressão por prazo
"Entrega sexta."
Mesmo sabendo que deveria levar três semanas.
Falta de testes
"Depois escrevemos."
Nunca escrevem.
Documentação inexistente
"Todo mundo entende."
Dois anos depois ninguém entende.
Copiar código
CTRL+C
CTRL+V
CTRL+C
CTRL+V
Assim nasce o caos.
Arquitetura improvisada
Funciona.
Mas ninguém sabe explicar.
Falta de revisão
Sem Code Review...
os problemas entram em produção.
Falta de treinamento
Programadores repetem erros porque nunca aprenderam alternativas melhores.
A dívida nem sempre é ruim
Essa é uma curiosidade interessante.
Nem toda dívida técnica é um erro.
Imagine um banco.
Existe uma exigência legal.
Prazo:
48 horas.
A equipe decide criar uma solução provisória.
Entrega.
Banco evita multas.
Depois reserva tempo para refatorar.
Excelente decisão.
Foi uma dívida consciente.
Dívida consciente x dívida inconsciente
Dívida consciente
"Sabemos que esse código está temporário."
Existe plano.
Existe prazo.
Existe orçamento.
Dívida inconsciente
"Nunca percebemos que fizemos errado."
Muito mais perigosa.
Os juros da dívida
Todo empréstimo possui juros.
Software também.
Os juros aparecem como:
Mais tempo para manutenção
Uma alteração simples leva dias.
Bugs recorrentes
Conserta um.
Quebra outro.
Medo
"Não mexe."
Frase clássica do legado.
Performance
Cada remendo adiciona processamento.
No mainframe isso significa:
CPU
MIPS
consumo
custo
Novos profissionais demoram meses
Porque entender ficou difícil.
Como a dívida cresce?
Imagine um cartão de crédito.
Primeiro mês:
100 reais.
Segundo mês:
Terceiro:
Depois:
Depois:
Software faz exatamente isso.
Cada nova funcionalidade construída sobre código ruim aumenta exponencialmente a complexidade.
O Mainframe sofre muito?
Curiosamente...
sim.
E não.
Mainframes normalmente possuem código extremamente robusto.
Mas muitos sistemas existem há quarenta anos.
Durante quatro décadas...
centenas de programadores passaram por eles.
Cada geração deixou pequenas modificações.
O resultado pode ser:
GOTO esquecidos
IFs duplicados
COPYBOOKS redundantes
programas gigantescos
tabelas obsoletas
JCLs nunca revisados
Um exemplo realista
Imagine um programa COBOL chamado:
PGMFIN01
1988
2.300 linhas.
1992
3.800 linhas.
1998
6.500 linhas.
2007
11.000 linhas.
2016
19.000 linhas.
2026
41.000 linhas.
Ninguém teve coragem de dividir.
Cada manutenção ficou mais cara.
A dívida cresceu silenciosamente.
O Oráculo explica
No universo Matrix, o Oráculo nunca entrega respostas prontas.
Ela oferece entendimento.
Na Engenharia de Software acontece igual.
A dívida técnica raramente aparece em relatórios.
Ela aparece nos sintomas.
Equipe cansada.
Prazo aumentando.
Mudanças simples demorando semanas.
Clientes reclamando.
ABENDs aparecendo após pequenas alterações.
Esses são os sinais.
Como reduzir a dívida?
Refatoração
Melhorar código sem alterar comportamento.
É a principal arma.
Testes automatizados
Permitem mudar com segurança.
Revisão de código
Dois olhos veem mais que um.
Arquitetura
Planejamento evita improvisos.
Documentação viva
Nunca deixe conhecimento apenas na memória.
Pair Programming
Conhecimento compartilhado.
Mentoria
Programadores experientes aceleram iniciantes.
Limpeza contínua
Nunca espere uma grande reescrita.
Melhore um pouco todos os dias.
A Regra do Escoteiro
Robert C. Martin popularizou uma ideia simples:
Deixe o código um pouco melhor do que encontrou.
Imagine milhares de desenvolvedores fazendo isso durante anos.
A dívida diminui naturalmente.
Atenção!
Existe um erro muito comum.
Confundir:
Refatoração
com
Reescrita.
São coisas completamente diferentes.
Refatorar melhora.
Reescrever substitui.
Nem sempre reescrever é inteligente.
Muitos projetos falharam tentando "começar do zero".
O perigo da Grande Reescrita
Na Matrix Reloaded, Neo descobre que destruir tudo não resolve.
Em software acontece igual.
Jogar fora um sistema COBOL de quarenta anos pode significar perder décadas de conhecimento de negócio.
O ideal é evoluir gradualmente.
Ferramentas que ajudam
Hoje existem excelentes ferramentas.
IBM ADDI
IBM Application Discovery
SonarQube
IBM COBOL Check
IBM Z Open Editor
IBM Developer for z/OS
GitHub Copilot
ChatGPT
Claude
ZUnit
Elas ajudam a identificar:
duplicações
complexidade
dependências
código morto
riscos
Sinais de alerta
Você deve investigar dívida técnica quando ouvir frases como:
"Não sabemos por que funciona."
"Não mexe nesse módulo."
"Compila assim mesmo."
"Só o João entende."
"Depois documentamos."
"Tem um GOTO aí... mas deixa."
"É gambiarra temporária."
Seis meses depois...
continua igual.
O papel do Programador COBOL Padawan
Um Padawan costuma pensar:
"Meu trabalho é escrever código."
Na verdade, não.
Seu trabalho é entregar soluções sustentáveis.
Sempre pergunte:
Isso poderá ser entendido daqui cinco anos?
Outro programador conseguirá manter?
Existe teste?
Existe documentação?
Existe duplicação?
Essa regra deveria estar em um COPYBOOK?
Esse programa precisa mesmo crescer mais mil linhas?
Essas perguntas evitam que você alimente a Matrix com novos Agentes Smith.
Curiosidades sobre a Dívida Técnica
Existem empresas que dedicam 20% do tempo de desenvolvimento apenas para pagar dívida técnica.
Grandes bancos mantêm backlogs exclusivos de refatoração, separados das novas funcionalidades.
Algumas organizações medem a dívida técnica com ferramentas que estimam quantos dias de trabalho seriam necessários para corrigir todos os problemas encontrados.
Em projetos críticos, reduzir dívida técnica pode gerar economia significativa em horas de manutenção, consumo de CPU, incidentes e retrabalho.
Outros "parentes" da Dívida Técnica
Ela costuma caminhar ao lado de diversos conceitos conhecidos:
Code Smell – sinais de que algo pode estar mal projetado.
Big Ball of Mud – sistema sem arquitetura definida.
Spaghetti Code – código confuso e altamente acoplado.
God Object – um único módulo faz tudo.
Bus Factor – conhecimento concentrado em poucas pessoas.
Shotgun Surgery – uma pequena alteração exige modificar dezenas de arquivos.
Lava Flow – código antigo que ninguém remove por medo.
Todos esses conceitos frequentemente aparecem juntos.
A Grande Escolha: Pílula Azul ou Pílula Vermelha?
No final de Matrix, Neo percebe que conhecer a verdade traz responsabilidade.
Na Engenharia de Software acontece exatamente o mesmo.
Você pode escolher a pílula azul:
copiar código;
ignorar testes;
adiar documentação;
aceitar "gambiarras permanentes";
acreditar que "funcionando está bom".
Ou pode escolher a pílula vermelha:
compreender a arquitetura;
investir em refatoração;
escrever código legível;
compartilhar conhecimento;
documentar regras de negócio;
pensar no próximo programador que abrirá aquele programa COBOL daqui a dez anos.
A primeira opção parece mais rápida, mas cobra juros crescentes. A segunda exige disciplina, porém constrói sistemas resilientes que atravessam décadas — exatamente como os grandes sistemas IBM Z que sustentam bancos, seguradoras, governos e companhias aéreas ao redor do mundo.
No universo Bellacosa Mainframe, a maior lição é clara: o inimigo não é o legado; é o legado abandonado. Sistemas COBOL envelhecem muito bem quando recebem manutenção consciente, arquitetura sólida e equipes comprometidas em reduzir continuamente a dívida técnica. Assim como Neo precisou aprender a enxergar além do código verde da Matrix, o Programador COBOL Padawan precisa aprender a enxergar além da próxima entrega e pensar no impacto que cada linha escrita hoje terá no futuro da organização.
Porque, no fim, toda dívida será paga. A única dúvida é quem pagará a conta: você hoje ou toda a equipe amanhã?
Sem comentários:
Enviar um comentário