 |
| Bellacosa Mainframe e os 3 bugs invisiveis do padawan cobol |
☕ Um Café no Bellacosa Mainframe
Os Três Bugs Invisíveis do Padawan COBOL
Como vencer a hesitação, a ingenuidade e o excesso de confiança antes que eles provoquem o primeiro ABEND da sua carreira
"O primeiro programa raramente derruba o banco. O primeiro erro de julgamento, sim."
Introdução
Existe um momento curioso na carreira de praticamente todo programador COBOL.
Não importa se ele estudou durante seis meses, um ano ou cinco anos.
Não importa se tirou certificações IBM.
Não importa se domina PROCEDURE DIVISION, PERFORM VARYING, OCCURS DEPENDING ON, SQL EMBEDDED, CICS ou VSAM.
O verdadeiro teste começa no primeiro dia em produção.
É ali que nasce o verdadeiro programador.
Durante décadas observando profissionais entrando em grandes bancos, seguradoras, empresas aéreas, órgãos públicos e processadoras de cartões, percebi um padrão curioso.
Os novatos quase nunca fracassam por falta de conhecimento técnico.
Eles tropeçam em três inimigos invisíveis.
São eles:
Hesitação
Ingenuidade
Excesso de confiança
Esses três defeitos aparecem em praticamente toda profissão crítica.
Na aviação.
Na medicina.
Na engenharia.
Na investigação criminal.
E, principalmente, em ambientes IBM Mainframe.
O curioso é que eles aparecem em momentos diferentes da evolução profissional.
E quase sempre na mesma ordem.
Hoje vamos investigar cada um deles como se estivéssemos em um episódio de CSI.
Porque um sistema crítico deixa rastros.
E a mente do programador também.
Cena do Crime 1
A Hesitação
Imagine a seguinte situação.
Você acabou de entrar na empresa.
Seu líder diz:
"Precisamos alterar o programa FINA340."
Você abre o programa.
28.000 linhas.
Escrito em 1989.
Última alteração:
há quatro dias.
Autores:
João
Carlos
Equipe Y2K
Projeto PIX
Open Banking
Adequação LGPD
Você olha aquilo.
O cursor pisca.
Cinco minutos.
Dez minutos.
Quinze minutos.
Você simplesmente não consegue tocar em nada.
Isso é completamente normal.
O cérebro entra em modo de sobrevivência
Nosso cérebro odeia destruir algo que parece importante.
Quanto maior a responsabilidade...
Maior a hesitação.
É um mecanismo biológico.
O problema é que hesitação excessiva paralisa.
E um programador parado não aprende.
O primeiro segredo
Veteranos não têm menos medo.
Eles apenas sabem investigar antes.
Essa é uma diferença gigantesca.
O novato pensa:
"Vou alterar."
O veterano pensa:
"Vou entender."
O método Bellacosa
Nunca altere antes de responder:
O que este programa faz?
Quem chama este programa?
Quem ele chama?
Quais arquivos atualiza?
Quais tabelas Db2 altera?
Existe rollback?
Existe commit?
Existe checkpoint?
Existe controle de versão?
Existe scheduler?
Existe impacto batch?
Existe impacto online?
Existe interface MQ?
Existe interface CICS?
Existe API?
Quando todas essas respostas aparecem...
A hesitação desaparece.
Porque ela foi substituída por conhecimento.
Easter Egg
Sherlock Holmes dizia:
"É um erro teorizar antes de possuir os fatos."
Todo programador COBOL deveria colocar essa frase no monitor.
Cena do Crime 2
A Ingenuidade
Depois do primeiro mês...
A hesitação diminui.
Agora nasce outro inimigo.
O iniciante acredita em tudo.
Documentação.
Comentários.
Fluxogramas.
Diagramas.
PowerPoint.
Wiki.
Chamados.
Manuais.
A maior mentira do Mainframe
Imagine encontrar isso:
* Atualiza somente clientes ativos
Bonito.
Organizado.
Profissional.
Mas você olha o código...
MOVE "S" TO WS-ATIVO
Nada mais.
Nenhuma validação.
Nenhuma regra.
Nenhum IF.
O comentário está errado há quinze anos.
Quem escreveu?
Provavelmente alguém que saiu da empresa em 2004.
A documentação envelhece
Código muda.
Documentação nem sempre.
O sistema continua funcionando.
Mas o documento virou arqueologia.
É como encontrar um mapa romano tentando dirigir em São Paulo.
A regra de ouro
Nunca confie totalmente em:
Comentários
Diagramas
Documentação
Fluxogramas
Apresentações
Emails antigos
Confie no comportamento do sistema.
Ele não mente.
Curiosidade
Muitos bancos possuem documentação cuja última atualização ocorreu antes do PIX existir.
O sistema evoluiu.
O documento não.
Cena do Crime 3
O Excesso de Confiança
Esse é o mais perigoso.
Porque normalmente aparece depois dos primeiros sucessos.
Você já resolveu alguns chamados.
Corrigiu ABEND.
Alterou tela CICS.
Fez alguns programas.
Agora pensa:
"Estou dominando."
É aí que mora o perigo.
O efeito Dunning-Kruger no Mainframe
Existe um fenômeno psicológico famoso.
Quanto menos sabemos...
Mais acreditamos saber.
Depois de alguns anos...
Percebemos o tamanho do universo.
É curioso.
O profissional de cinco meses costuma parecer mais confiante que o de vinte anos.
Porque ainda não descobriu tudo o que desconhece.
O veterano faz mais perguntas
O iniciante responde rápido.
O veterano pergunta mais.
Isso parece contraditório.
Mas faz sentido.
O veterano conhece centenas de armadilhas.
Ele sabe que sistemas críticos escondem surpresas.
Exemplo clássico
Você altera:
IF SALDO > 0
Parece simples.
Mas esquece que existe outro programa batch.
Outro online.
Outro scheduler.
Outro MQ.
Outro API Gateway.
Outro processo noturno.
Outro job semanal.
Outro fechamento mensal.
Outro processamento anual.
Seu IF alterou uma cadeia inteira.
O código nunca vive sozinho
Essa talvez seja a maior descoberta da carreira.
Programas COBOL não são ilhas.
São organismos.
Cada programa conversa com dezenas de outros.
Às vezes centenas.
Você altera uma linha.
Pode movimentar uma cidade inteira.
CSI Mainframe
Imagine Gil Grissom entrando no CPD.
Ele nunca começaria perguntando:
"Quem é o culpado?"
Ele perguntaria:
"O que aconteceu primeiro?"
Depois:
"O que mudou?"
Depois:
"Quem foi impactado?"
É exatamente assim que um analista experiente investiga incidentes.
Indiana Jones no Data Center
O código legado lembra uma cidade perdida.
Você entra com uma tocha.
Cada COPYBOOK é uma sala.
Cada PERFORM é um corredor.
Cada CALL é uma porta secreta.
Cada JCL é um mapa.
Cada PROC é um túnel subterrâneo.
E cada alteração pode ativar uma armadilha escondida.
O aventureiro imprudente corre.
O arqueólogo observa.
A Regra dos Cinco "Por Quês"
Sempre pergunte:
Por que isso existe?
Por que foi escrito assim?
Por que não removeram?
Por que ainda funciona?
Por que ninguém mexe nisso?
A quinta resposta normalmente revela uma decisão de negócio esquecida.
O Erro Mais Caro
Não é apagar um arquivo.
Nem provocar um ABEND.
Nem esquecer um END-IF.
O erro mais caro é assumir.
Assumir que entendeu.
Assumir que ninguém usa.
Assumir que é simples.
Assumir que o comentário está correto.
Assumir que aquele campo nunca recebe zeros.
Mainframe odeia suposições.
O Poder da Humildade Técnica
Existe uma frase muito comum entre grandes especialistas IBM.
"Não sei. Vamos verificar."
Observe.
Eles não respondem imediatamente.
Eles investigam.
Essa postura não demonstra fraqueza.
Demonstra maturidade.
O Ritual Bellacosa Antes de Alterar Qualquer Programa
Criei ao longo dos anos um pequeno ritual que evita boa parte dos problemas em produção. Antes de salvar qualquer alteração, faça estas perguntas:
Entendi exatamente qual é o problema de negócio?
Descobri todos os programas envolvidos?
Verifiquei os COPYBOOKs relacionados?
Analisei impactos em Db2, VSAM, CICS ou IMS?
Procurei alterações semelhantes no histórico?
Executei testes com dados normais e dados extremos?
Pensei no que acontece se um campo vier vazio, nulo ou inesperado?
Existe plano de retorno (rollback) caso algo dê errado?
Alguém mais experiente revisou minha lógica?
Eu conseguiria explicar esta alteração para outra pessoa em cinco minutos?
Se alguma resposta for "não", ainda há investigação a fazer.
Os Três Mestres da Carreira
Todo grande profissional aprende a equilibrar três características:
Coragem
Para enfrentar programas enormes sem fugir.
Curiosidade
Para investigar antes de alterar.
Humildade
Para aceitar que sempre existe algo escondido no sistema.
Esses três pilares são muito mais importantes do que decorar todas as instruções do COBOL.
O Último Easter Egg
Na saga Star Wars, Luke Skywalker acreditava que vencer significava lutar melhor.
Yoda ensinou outra coisa.
Primeiro, controlar a própria mente.
Só depois controlar o sabre de luz.
No Mainframe acontece exatamente o mesmo.
O COBOL não é o sabre.
O sabre é apenas uma ferramenta.
O verdadeiro combate acontece dentro da cabeça do programador.
A hesitação precisa ser transformada em investigação.
A ingenuidade precisa ser substituída por validação.
O excesso de confiança precisa dar lugar à disciplina.
Quando isso acontece, nasce um profissional capaz de trabalhar em ambientes onde milhões de transações financeiras, folhas de pagamento, benefícios governamentais, seguros, cartões de crédito e operações bancárias dependem de algumas linhas de código escritas décadas atrás.
Conclusão — O Primeiro Grande Upgrade Não é no Código, é no Programador
No universo Bellacosa Mainframe, costumo dizer que existem dois tipos de iniciantes.
O primeiro acredita que aprender COBOL significa memorizar verbos, comandos, JCLs e utilitários. Ele mede seu progresso pela quantidade de sintaxes que conhece.
O segundo entende que COBOL é apenas a linguagem usada para conversar com um ecossistema gigantesco de regras de negócio, processos, integrações e pessoas. Ele mede seu progresso pela qualidade das perguntas que faz, pela capacidade de investigar antes de modificar e pela prudência ao assumir responsabilidades.
É esse segundo profissional que evolui para analista, arquiteto, líder técnico e mentor.
A verdadeira iniciação de um Padawan Mainframe não acontece quando ele compila seu primeiro programa sem erros. Ela acontece no dia em que percebe que um sistema legado é como um templo antigo: cada rotina foi construída por gerações diferentes, cada COPYBOOK guarda um pedaço da história da empresa e cada linha de código existe por um motivo — mesmo que esse motivo tenha sido esquecido pelo tempo.
Se você conseguir vencer a hesitação sem perder a prudência, abandonar a ingenuidade sem perder a curiosidade e controlar o excesso de confiança sem perder a coragem, terá desenvolvido a característica mais valiosa de todas: o julgamento técnico.
E julgamento técnico não se aprende em um manual. Ele é construído a cada investigação, a cada revisão de código, a cada incidente resolvido e a cada lição deixada por um erro.
No fim das contas, o maior sistema que um programador COBOL precisa aprender a administrar não é o z/OS, o CICS ou o Db2.
É a própria mente. Só quando ela trabalha de forma disciplinada, investigativa e humilde é que o restante do ecossistema Mainframe deixa de parecer um labirinto e passa a revelar sua verdadeira arquitetura. Nesse momento, o Padawan deixa de apenas escrever programas e começa, de fato, a pensar como um guardião dos sistemas que sustentam parte da economia do mundo.
Sem comentários:
Enviar um comentário