 |
| Bellacosa Mainframe como pagar dividas tecnicas em mainframe |
☕💣📋 HOW TO PAY BACK TECHNICAL DEBT — O DIA EM QUE O PROGRAMADOR COBOL DESCOBRIU QUE ESTAVA PAGANDO JUROS POR UMA DECISÃO TOMADA EM 1998
Existe uma frase muito conhecida no mercado de tecnologia:
"Toda empresa tem dívida técnica. Algumas apenas ainda não receberam a cobrança."
Para um programador COBOL Mainframe júnior, a expressão "dívida técnica" parece algo moderno, criado por arquitetos ágeis, consultores de transformação digital ou gurus do DevOps.
Mas a verdade é muito mais divertida.
Muito antes de alguém inventar Scrum, Kanban, DevOps, GitHub ou Microservices, os programadores COBOL já acumulavam dívida técnica sem saber.
Toda vez que alguém dizia:
"Depois a gente arruma."
Nascia uma nova parcela.
E em muitos ambientes z/OS, ainda estamos pagando prestações de decisões tomadas há 20 ou 30 anos.
Pegue seu café porque hoje vamos entender como identificar, medir, controlar e pagar dívida técnica sem derrubar a produção.
O QUE É DÍVIDA TÉCNICA?
A definição mais simples é:
Dívida técnica é o custo futuro criado por uma decisão técnica tomada para resolver um problema rapidamente hoje.
Imagine um programa COBOL.
Você precisa entregar uma alteração urgente.
O correto seria:
Revisar arquitetura
Atualizar documentação
Criar testes
Refatorar módulos
Mas o prazo é amanhã.
Então alguém faz:
IF CLIENTE = '999999'
GO TO TRATAMENTO-ESPECIAL.
Entrega.
Produção funciona.
Cliente feliz.
Projeto encerrado.
Mas daqui a dois anos ninguém lembra por que aquele IF existe.
A dívida nasceu.
O MAIOR MITO DO MAINFRAME
Muita gente acredita que:
"Código antigo é dívida técnica."
Errado.
Código antigo pode ser excelente.
Existem programas COBOL escritos nos anos 80 que ainda hoje são exemplos de engenharia.
Por outro lado, existem programas escritos há seis meses que já nasceram endividados.
A idade do código não importa.
O que importa é:
Complexidade
Manutenibilidade
Clareza
Testabilidade
Documentação
COMO IDENTIFICAR DÍVIDA TÉCNICA
O primeiro passo é aprender a enxergá-la.
Alguns sintomas clássicos:
Programa que ninguém quer alterar
Quando uma demanda chega e todos falam:
"Tomara que não seja naquele programa..."
Existe dívida.
Alteração simples demora dias
Mudança:
Trocar 20 para 25.
Tempo gasto:
3 dias
Existe dívida.
Muitos abends
Se o mesmo módulo gera incidentes frequentemente:
S0C7
S0C4
SQLCODE negativos
Arquivos inconsistentes
Existe dívida.
Dependência de especialistas
Quando apenas uma pessoa entende o sistema.
Isso é uma dívida técnica humana.
Extremamente perigosa.
A METÁFORA DO CARTÃO DE CRÉDITO
A IBM utiliza uma analogia excelente.
Imagine um cartão.
Você compra algo hoje.
O benefício é imediato.
O pagamento fica para depois.
Dívida técnica funciona igual.
Benefício imediato:
Entreguei no prazo
Pagamento futuro:
Mais manutenção
Mais defeitos
Mais testes
Mais retrabalho
O problema não é usar o cartão.
O problema é esquecer da fatura.
COMO MAPEAR A DÍVIDA TÉCNICA
A primeira atividade prática é criar um inventário.
Monte uma planilha contendo:
| Sistema | Problema | Impacto | Prioridade |
|---|---|---|---|
| Cadastro | GO TO excessivo | Médio | Média |
| Cobrança | Sem documentação | Alto | Alta |
| Faturamento | Alta complexidade | Alto | Alta |
Você não consegue corrigir aquilo que não consegue enxergar.
MÉTRICA 1 – COMPLEXIDADE CICLOMÁTICA
Uma das métricas mais famosas.
Ela mede quantos caminhos lógicos existem em um programa.
Exemplo:
IF A
...
ELSE
...
END-IF
Pouca complexidade.
Agora imagine:
IF A
IF B
IF C
IF D
A complexidade explode.
Quanto maior a complexidade:
Mais difícil testar
Mais difícil manter
Maior risco de erro
Regra prática:
| Valor | Situação |
|---|---|
| 1 a 10 | Boa |
| 11 a 20 | Atenção |
| Acima de 20 | Risco |
MÉTRICA 2 – TEMPO DE MANUTENÇÃO
Métrica simples.
Quanto tempo leva para implementar uma mudança?
Exemplo:
Alteração simples:
4 horas
Virou:
3 dias
A dívida está cobrando juros.
MÉTRICA 3 – QUANTIDADE DE INCIDENTES
Monitore:
Chamados
Tickets
Problemas recorrentes
Se determinado programa gera:
20% dos incidentes
Ele deve entrar imediatamente no backlog técnico.
MÉTRICA 4 – COBERTURA DE TESTES
Quanto do sistema possui testes?
Exemplo:
10%
Muito arriscado.
80%
Muito saudável.
No mundo COBOL isso pode envolver:
Unit Test
Testes automatizados
Batch Validation
MÉTRICA 5 – TEMPO MÉDIO DE RECUPERAÇÃO
MTTR
Mean Time To Recovery.
Quanto tempo leva para resolver um problema?
Exemplo:
10 minutos
Excelente.
8 horas
Existe forte dívida técnica.
A REGRA DOS 20%
Uma prática muito utilizada é reservar:
80% desenvolvimento
20% redução de dívida técnica
Isso impede que a dívida cresça infinitamente.
TÉCNICA 1 – REFATORAÇÃO CONTÍNUA
Refatorar significa melhorar sem alterar comportamento.
Exemplo:
Antes:
GO TO ERRO.
GO TO ERRO.
GO TO ERRO.
Depois:
PERFORM TRATA-ERRO.
Mesmo resultado.
Código mais limpo.
TÉCNICA 2 – MODULARIZAÇÃO
Programas gigantes são fábricas de dívida.
Já encontrei programas com:
80.000 linhas
Divida responsabilidades.
Crie módulos menores.
Mais simples de entender.
Mais simples de testar.
TÉCNICA 3 – DOCUMENTAÇÃO VIVA
Documentação morta é inútil.
Documentação viva é atualizada junto com o sistema.
Documente:
Fluxos
Arquivos
Tabelas
Regras de negócio
TÉCNICA 4 – ELIMINAÇÃO DE CÓDIGO MORTO
Existe um cemitério escondido em todo sistema.
Trechos como:
IF FLAG = 'X'
Que nunca mais executam.
Remover código morto reduz:
Complexidade
Risco
Tempo de manutenção
TÉCNICA 5 – BACKLOG TÉCNICO
Crie um backlog específico.
Exemplo:
Remover GO TO
Documentar módulo
Automatizar teste
Eliminar código morto
A dívida precisa aparecer oficialmente.
Caso contrário ela nunca será priorizada.
FERRAMENTAS ÚTEIS NO MUNDO MAINFRAME
IBM Application Discovery
Mapeia dependências.
Mostra:
Programas
Arquivos
CICS
DB2
Excelente para arqueologia de sistemas.
IBM ADDI
Application Discovery and Delivery Intelligence.
Permite visualizar relacionamentos invisíveis.
Muito útil para sistemas legados.
SonarQube
Mesmo para COBOL.
Detecta:
Complexidade
Duplicação
Código suspeito
IBM Developer for z/OS
Auxilia:
Navegação
Análise
Refatoração
Jira
Controle de backlog técnico.
Muitas empresas utilizam para registrar dívida técnica.
EASTER EGG MAINFRAME
Quer descobrir rapidamente onde existe dívida?
Procure:
GO TO
ALTER
NEXT SENTENCE
Ou:
STEP099
STEP100
STEP101
Sem documentação.
Você provavelmente encontrou um sítio arqueológico corporativo.
O ERRO MAIS COMUM DOS JUNIORES
Pensar:
"Vou reescrever tudo."
Não.
Esse é o caminho para o desastre.
A melhor estratégia quase sempre é:
Pequenas melhorias contínuas.
Todo dia.
Toda sprint.
Todo projeto.
Toda manutenção.
COMO EVOLUIR COMO PROFISSIONAL
Programadores experientes não são aqueles que escrevem mais código.
São aqueles que reduzem complexidade.
Quando você consegue olhar para um sistema e dizer:
"Esse trecho vai gerar problema daqui a dois anos."
Você começou a pensar como arquiteto.
O SEGREDO DOS MELHORES ANALISTAS DE SISTEMAS
Eles não combatem apenas bugs.
Eles combatem as causas dos bugs.
Essa é a diferença entre apagar incêndios e construir sistemas duradouros.
CONCLUSÃO
Dívida técnica não é um defeito.
Ela é uma ferramenta.
Em alguns momentos vale a pena assumir a dívida para entregar rapidamente.
O problema surge quando ninguém controla o saldo.
O programador COBOL júnior que aprender a:
Identificar dívida
Medir dívida
Priorizar dívida
Reduzir dívida
Monitorar dívida
Terá uma visão muito mais próxima de um arquiteto de sistemas do que de um simples codificador.
Porque no fim das contas, o maior segredo do Mainframe não é fazer programas funcionarem.
É garantir que eles continuem funcionando daqui a 30 anos sem que alguém precise vender a alma para entender por quê.
