 |
| Bellacosa Mainframe e o covid expondo problemas da divida tecnica |
☕💣📋 A DÍVIDA TÉCNICA QUASE PAROU OS BANCOS — A COVID APERTOU ENTER E O SISTEMA REVELOU 40 ANOS DE PROBLEMAS ESCONDIDOS
O DIA EM QUE UM PROGRAMADOR COBOL JÚNIOR DESCOBRIU QUE O MAIOR BUG DO BANCO NÃO ESTAVA NO CÓDIGO
Imagine a seguinte situação.
Você acabou de entrar em um grande banco.
Recebe seu primeiro programa COBOL para manutenção.
Abre o membro no ISPF.
O programa possui:
28.000 linhas
134 COPYBOOKS
742 parágrafos
Comentários da época do Plano Real
Um PERFORM THRU que ninguém entende
Um campo chamado WK-AREA1
Outro chamado WK-AREA2
Outro chamado WK-AREA3
E você pensa:
"Quem foi o maluco que escreveu isso?"
Então um analista veterano olha para você e responde:
— Eu.
E completa:
— Em 1998 aquilo era considerado moderno.
Nesse momento você acabou de conhecer um dos conceitos mais importantes da engenharia de software:
Dívida Técnica
O QUE É DÍVIDA TÉCNICA?
A melhor definição é simples.
Dívida técnica é quando uma decisão que economiza tempo hoje gera custos maiores amanhã.
Funciona exatamente como um empréstimo bancário.
Você pega dinheiro hoje.
Mas depois paga:
principal
juros
correção
multas
No software acontece a mesma coisa.
Você ganha velocidade agora.
Mas perde produtividade no futuro.
EXEMPLO COBOL CLÁSSICO
Imagine que em 1998 alguém criou:
IF AGENCIA = 1234
MOVE 'SANTOS' TO CIDADE
END-IF
Parecia inofensivo.
Hoje existem:
3.000 agências
dezenas de fusões
múltiplas marcas
Agora o código virou:
IF AGENCIA = 1234
...
ELSE IF AGENCIA = 2345
...
ELSE IF AGENCIA = 3456
...
O que era uma solução virou um problema.
COMO A DÍVIDA TÉCNICA NASCE?
Normalmente através de frases famosas.
Frase 1
"Depois a gente melhora."
Mentira.
Ninguém melhora.
Frase 2
"É só uma correção rápida."
Nunca é.
Frase 3
"O projeto fecha sexta-feira."
A dívida nasce quinta.
Frase 4
"Não mexe porque funciona."
O terror dos bancos.
OS TIPOS DE DÍVIDA TÉCNICA
1. Código
Programas difíceis de entender.
Exemplos:
GOTO excessivo
PERFORM THRU gigantes
variáveis sem significado
duplicação
2. Arquitetura
Problemas maiores.
Exemplos:
sistemas monolíticos
dependências excessivas
integrações frágeis
3. Dados
Muito comum em bancos.
Exemplos:
arquivos VSAM redundantes
tabelas DB2 duplicadas
dados inconsistentes
4. Processos
Pouco discutida.
Mas extremamente perigosa.
Exemplos:
deploy manual
testes manuais
documentação inexistente
COMO IDENTIFICAR DÍVIDA TÉCNICA?
Um júnior costuma perguntar:
"Como sei que existe dívida?"
Observe sintomas.
Sintoma 1
Mudanças simples levam semanas.
Sintoma 2
Toda alteração gera incidente.
Sintoma 3
Poucas pessoas entendem o sistema.
Sintoma 4
Ninguém quer mexer.
Sintoma 5
A frase mais perigosa:
"Esse programa é do fulano."
Quando o sistema tem dono humano, existe dívida.
MÉTRICAS IMPORTANTES
Agora entramos em uma área que diferencia profissionais comuns de profissionais de elite.
Você não gerencia aquilo que não mede.
1. COMPLEXIDADE CICLOMÁTICA
Criada por Thomas McCabe.
Mede quantos caminhos lógicos existem.
Exemplo:
IF A
...
ELSE
...
END-IF
Complexidade = 2
Agora imagine 300 IFs.
O número explode.
Quanto maior:
mais difícil testar
mais difícil manter
maior risco
Meta saudável:
abaixo de 10 excelente
até 20 aceitável
acima de 30 perigoso
2. LINHAS DE CÓDIGO
LOC (Lines of Code)
Não mede qualidade.
Mas mede tamanho.
Programa COBOL:
500 linhas → simples
5.000 linhas → atenção
20.000 linhas → investigação
3. DUPLICAÇÃO DE CÓDIGO
Quanto código está repetido?
Exemplo:
Mesma regra de cálculo em:
cadastro
empréstimo
cartão
investimentos
Quando muda uma regra:
quatro programas precisam mudar.
4. COBERTURA DE TESTES
Quanto do sistema é validado?
Métrica:
Cobertura = código testado / código total
Quanto maior, melhor.
5. TEMPO MÉDIO DE CORREÇÃO
MTTR
Mean Time To Repair.
Quanto tempo leva para corrigir problemas.
Quanto menor:
melhor maturidade.
6. DEFEITOS POR RELEASE
Muito utilizada em bancos.
Pergunta simples:
Quantos incidentes surgem após implantação?
FERRAMENTAS QUE AJUDAM
Vamos ao arsenal.
IBM APPLICATION DISCOVERY
Conhecida como AD.
Excelente para:
dependências
impacto
análise de código
Mostra relacionamentos invisíveis.
IBM APPLICATION DELIVERY FOUNDATION
Ajuda em:
DevOps
testes
integração
SONARQUBE
Uma das mais famosas.
Analisa:
complexidade
duplicação
vulnerabilidades
Possui suporte para COBOL.
TOPAZ
Muito utilizada em ambientes Compuware/BMC.
Excelente para:
visualização
debugging
análise
ENDEVOR
Ajuda no controle de versões.
Embora não seja ferramenta de dívida técnica, ajuda a evitar que ela cresça.
GIT
Sim.
Programadores COBOL modernos usam Git.
O mundo mudou.
COMO REDUZIR DÍVIDA TÉCNICA?
Agora chegamos à parte prática.
PASSO 1
MAPEAR
Nunca saia corrigindo.
Primeiro descubra:
onde está
quanto existe
qual impacto
PASSO 2
CLASSIFICAR
Separe em:
Alta prioridade
Afeta negócio.
Média prioridade
Afeta produtividade.
Baixa prioridade
Apenas estética.
PASSO 3
ATACAR O TOPO
Use a regra 80/20.
Normalmente:
20% dos programas geram 80% dos problemas.
Comece por eles.
PASSO 4
REFATORAR
Refatorar significa:
melhorar sem alterar comportamento.
Exemplo:
Antes
MOVE 'S' TO WS-FLAG1
Depois
MOVE 'S' TO WS-CLIENTE-ATIVO
Mesmo resultado.
Melhor compreensão.
PASSO 5
REMOVER DUPLICAÇÃO
Regra de ouro.
Se existe em cinco lugares.
Transforme em um.
PASSO 6
DOCUMENTAR
A documentação mais barata é aquela escrita hoje.
A mais cara é aquela que será escrita daqui cinco anos.
PASSO 7
CRIAR APIs
Aqui entra a modernização.
Não destrua o COBOL.
Encapsule.
Exemplo:
Mobile
|
API
|
CICS
|
COBOL
|
DB2
O COBOL continua funcionando.
Mas agora conversa com o mundo moderno.
O PAPEL DA CLOUD
Muitos profissionais acreditam:
"Cloud substitui Mainframe."
Não.
A realidade é:
Cloud complementa Mainframe.
O mercado está migrando para:
Mainframe + APIs + Cloud + IA
Não:
Mainframe versus Cloud
EASTER EGG DA INDÚSTRIA
Você sabia?
Grande parte dos sistemas bancários mais críticos do planeta possui código executando há décadas.
Alguns módulos possuem mais idade que muitos programadores que fazem manutenção neles.
CURIOSIDADE
Em muitos bancos existem programas COBOL executados diariamente há mais de 30 anos sem interrupção significativa.
Pouquíssimas tecnologias no mundo podem afirmar isso.
A REGRA DOS ESCOTEIROS
Uma das melhores técnicas contra dívida técnica.
Conhecida como:
Boy Scout Rule
"Deixe o código mais limpo do que encontrou."
Você corrige um bug.
Aproveite para:
melhorar nomes
remover comentários obsoletos
eliminar duplicações
Pequenas melhorias acumulam enormes resultados.
O ERRO QUE TODO JÚNIOR COMETE
Querer reescrever tudo.
Não faça isso.
Sistemas bancários existem para:
processar pagamentos
movimentar bilhões
atender clientes
Não para serem bonitos.
Primeiro entenda.
Depois melhore.
Por último modernize.
O CAMINHO DE EVOLUÇÃO PROFISSIONAL
Júnior:
"Como funciona?"
Pleno:
"Como melhorar?"
Sênior:
"Como evitar que o problema volte?"
Arquiteto:
"Como impedir que o problema exista?"
☕🦠💣 QUANDO A COVID FEZ O IPL DO PLANETA E REVELOU TODOS OS ABENDS ESCONDIDOS DOS BANCOS
Até 2020 muitos bancos acreditavam que estavam preparados para o futuro.
Possuíam:
Internet Banking
Aplicativos móveis
Chatbots
APIs
Transformação Digital nos PowerPoints
Então chegou a COVID.
E a realidade apareceu.
O TESTE DE STRESS QUE NINGUÉM PLANEJOU
Durante décadas os bancos planejavam crescimento gradual.
De repente aconteceu:
Milhões de clientes
tentando acessar
os sistemas ao mesmo tempo
O equivalente em mainframe seria:
100.000 jobs
entrando na fila
simultaneamente
O QUEBROU?
Curiosamente, muitas vezes não foi o COBOL.
Nem o CICS.
Nem o DB2.
Foi a camada moderna.
Por exemplo:
Portais Web
Gateways API
Aplicativos móveis
Centrais de atendimento
Os sistemas core continuavam funcionando.
Mas os canais de acesso colapsaram.
O DIA EM QUE O BANCO DESCOBRIU SUA DÍVIDA TÉCNICA
Muitas instituições descobriram:
Processos manuais escondidos
Dependência excessiva de funcionários específicos
Sistemas sem escalabilidade
Arquiteturas ultrapassadas
A pandemia funcionou como um scanner de vulnerabilidades em escala mundial.
☁️ A NUVEM NÃO É UMA MÁQUINA. É UMA ESTRATÉGIA.
Um dos maiores erros dos iniciantes é pensar:
Cloud = Servidor em outro lugar
Não.
Cloud é uma mudança de modelo operacional.
O QUE A NUVEM OFERECE?
Imagine que amanhã o banco precise processar:
10 vezes mais transações
No modelo tradicional:
Comprar servidores
Instalar servidores
Configurar servidores
Meses de trabalho.
NA NUVEM
Precisa de mais capacidade?
Adiciona.
Precisa de menos?
Remove.
A NUVEM REDUZ DÍVIDA TÉCNICA?
Resposta curta:
Não.
RESPOSTA LONGA
A nuvem não elimina dívida técnica.
Mas torna muito mais fácil combatê-la.
Exemplo:
Antes:
Sistema monolítico
30.000 programas
Depois:
Microserviços
APIs
Containers
Agora você consegue modernizar partes isoladas.
O PADRÃO QUE ESTÁ DOMINANDO OS BANCOS
O mercado financeiro está migrando para:
Cloud
|
APIs
|
Mainframe
|
DB2
Não:
Cloud substituindo Mainframe
Mas:
Cloud consumindo Mainframe
Essa diferença é gigantesca.
O STRANGLER PATTERN
Um dos segredos da modernização bancária.
Ao invés de destruir:
Sistema COBOL
Você faz:
Nova API
Depois:
Novo serviço
Depois:
Novo canal digital
E o legado vai sendo cercado gradualmente.
👨💼 O PROBLEMA QUE NINGUÉM GOSTA DE DISCUTIR: RH
A parte mais interessante da entrevista da IBM talvez seja esta:
A maior dívida técnica não é financeira.
É humana.
O PROGRAMA COBOL QUE APOSENTOU O FUNCIONÁRIO
Imagine:
Programa:
PAGBOL01
Criado em:
1994
Quem entende?
Uma pessoa.
O DIA DO DESASTRE
Essa pessoa:
aposenta
muda de empresa
entra em férias
Pronto.
Agora existe um risco operacional.
O FATOR ÔNIBUS
Métrica famosa.
Pergunta:
Quantas pessoas precisam desaparecer para que o projeto pare?
Se a resposta for:
1
Você possui um problema grave.
O QUE OS JOVENS DESENVOLVEDORES PROCURAM?
A nova geração busca:
Git
APIs
DevOps
Cloud
Automação
CI/CD
Não necessariamente porque são modismos.
Mas porque aumentam produtividade.
O ERRO DOS GESTORES
Muitos acreditam:
"Os jovens não querem aprender COBOL."
Errado.
O que eles não querem é:
Trabalhar em caos.
Existe uma enorme diferença.
UM COBOL MODERNO É ATRAENTE
Imagine um ambiente com:
Git
VS Code
Zowe
APIs REST
Jenkins
SonarQube
E atrás disso:
COBOL
CICS
DB2
O profissional moderno trabalha feliz.
UM COBOL ANTIGO É REPELENTE
Agora imagine:
documentação inexistente
deploy manual
FTP
planilhas Excel
mudanças sem controle
O problema não é COBOL.
É a cultura.
O CUSTO INVISÍVEL DA DÍVIDA TÉCNICA
Os gestores normalmente medem:
hardware
software
licenças
Mas esquecem:
turnover
treinamento
conhecimento perdido
Esses custos podem superar os custos tecnológicos.
O CICLO VICIOSO
A dívida técnica cria:
Sistema ruim
↓
Pouca produtividade
↓
Mais pressão
↓
Mais atalhos
↓
Mais dívida técnica
↓
Mais pessoas saem
↓
Menos conhecimento
↓
Mais dívida técnica
É um círculo destrutivo.
O CICLO VIRTUOSO
A modernização cria:
Melhor arquitetura
↓
Mais produtividade
↓
Menos incidentes
↓
Mais inovação
↓
Mais satisfação
↓
Melhor retenção
↓
Mais conhecimento
↓
Menos dívida técnica
A GRANDE LIÇÃO PARA O PROGRAMADOR COBOL JÚNIOR
Quando você ouvir a expressão:
"Precisamos migrar para a nuvem."
Não pense em servidores.
Pense em:
agilidade
automação
integração
APIs
escalabilidade
experiência do desenvolvedor
Quando ouvir:
"Precisamos reduzir dívida técnica."
Não pense apenas em código.
Pense em:
pessoas
conhecimento
processos
documentação
cultura
E quando ouvir:
"Precisamos modernizar o mainframe."
Lembre-se:
Os maiores bancos do mundo não estão abandonando COBOL.
Eles estão cercando COBOL com tecnologias modernas para que ele continue entregando valor pelos próximos 30 anos.
CONCLUSÃO
A maior lição sobre dívida técnica é surpreendente.
O problema raramente é COBOL.
O problema quase sempre é falta de gestão.
Um programa COBOL de 1985 pode ser extremamente moderno se possuir:
documentação
testes
APIs
observabilidade
versionamento
arquitetura bem definida
Da mesma forma, uma aplicação criada ontem pode nascer cheia de dívida técnica.
Lembre-se sempre:
Dívida técnica não é idade.
Dívida técnica é descuido acumulado.
E existe uma enorme diferença entre um sistema antigo e um sistema mal cuidado.
O programador COBOL que entender essa diferença deixa de ser apenas um mantenedor de código legado e passa a ser um verdadeiro engenheiro responsável por preservar, modernizar e evoluir alguns dos sistemas mais importantes do planeta.
