Translate

Mostrar mensagens com a etiqueta testes de software. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta testes de software. Mostrar todas as mensagens

sábado, 4 de outubro de 2025

☕💾🔥 ENGENHARIA DE SOFTWARE — O “SISTEMA OPERACIONAL INVISÍVEL” QUE SEPARA PROGRAMADORES COMUNS DE PROFISSIONAIS ENTERPRISE 🔥💾☕

 

Bellacosa Mainframe e a Engenharia de Software

☕💾🔥 ENGENHARIA DE SOFTWARE — O “SISTEMA OPERACIONAL INVISÍVEL” QUE SEPARA PROGRAMADORES COMUNS DE PROFISSIONAIS ENTERPRISE 🔥💾☕

Muita gente entrando no mundo COBOL/mainframe acredita que:

“Engenharia de software = aprender linguagem.”

☠️🔥

Mas aí acontece o primeiro trauma corporativo real:

  • ABEND em produção;
  • batch atrasado;
  • janela estourada;
  • rollback;
  • incidente crítico;
  • auditoria;
  • problema de performance DB2;
  • mudança quebrando outro sistema;
  • integração falhando às 3h da manhã.

E nesse momento o programador descobre:

Engenharia de software NÃO é apenas programar.

Ela é:

  • organização;
  • arquitetura;
  • previsibilidade;
  • qualidade;
  • processos;
  • sobrevivência operacional.

☕ O QUE É ENGENHARIA DE SOFTWARE DE VERDADE?

Engenharia de software é:

construir sistemas grandes, confiáveis, escaláveis e sustentáveis sem transformar a empresa num apocalipse tecnológico.

🔥💾☕


O ERRO MAIS COMUM DO PROGRAMADOR JÚNIOR

O iniciante normalmente pensa assim:

“Se compilou e rodou, está pronto.”

☠️☠️☠️

No mundo enterprise isso NÃO significa nada.

Porque um software corporativo precisa:

  • funcionar;
  • escalar;
  • ser seguro;
  • ser auditável;
  • ser documentado;
  • sobreviver anos;
  • suportar manutenção;
  • integrar com dezenas de sistemas;
  • não destruir produção.

☕💾 O MAINFRAME ENSINOU ISSO MUITO ANTES DA CLOUD

A ironia é fantástica.

Hoje o mercado fala:

  • DevOps;
  • SRE;
  • observabilidade;
  • resiliência;
  • alta disponibilidade;
  • governança.

Mas o mundo mainframe já fazia isso desde os anos 70.

🔥☕


UM PROGRAMADOR COBOL NÃO ESCREVE “APENAS PROGRAMAS”

Ele frequentemente participa de:

  • sistemas bancários;
  • processamento de folha;
  • cartões;
  • PIX;
  • compensação;
  • seguros;
  • governo;
  • telecom.

Ou seja:

software que movimenta bilhões.


☕ A DIFERENÇA ENTRE “CODAR” E “ENGENHARIA”

Programador comum

“Vou fazer funcionar.”

Engenheiro de software

“Como isso vai sobreviver 15 anos em produção?”

🔥💾


O SDLC — O CICLO DA SOBREVIVÊNCIA CORPORATIVA

Toda empresa séria usa algum tipo de SDLC.

Software Development Life Cycle


As etapas clássicas

Requirements

Design

Development

Testing

Deployment

Maintenance

☕ O QUE O JÚNIOR NORMALMENTE NÃO PERCEBE

O código é apenas UMA etapa pequena.

Grande parte do esforço real está em:

  • entender negócio;
  • validar regras;
  • testar;
  • homologar;
  • documentar;
  • subir produção;
  • monitorar;
  • manter.

☠️ O MAIOR CEMITÉRIO DA TI

Projetos falham mais por:

  • requisitos ruins;
  • arquitetura ruim;
  • falta de comunicação;
  • falta de testes;

do que por linguagem.


☕💾 REQUISITOS — O “BUG” QUE NASCE ANTES DO CÓDIGO

Muitos sistemas falham porque:

o time implementou corretamente…
o requisito errado.

☠️🔥


Exemplo COBOL clássico

Usuário diz:

“quero calcular juros.”

Mas ninguém definiu:

  • regra;
  • arredondamento;
  • calendário;
  • horário;
  • feriados;
  • timezone;
  • tratamento de exceção.

☠️☠️☠️

Resultado:

  • prejuízo;
  • auditoria;
  • incidente;
  • caos.

☕ TESTES — O SEGURO DE VIDA DO ENTERPRISE

Programador júnior frequentemente pensa:

“Mas na minha máquina funcionou.”

☠️🔥☠️🔥☠️🔥

Produção enterprise não perdoa isso.


Tipos de teste

Functional

A regra funciona?


Performance

Aguenta milhões de transações?


Regression

A correção quebrou outro sistema?


Security

Existe vulnerabilidade?


☕💾 MAINFRAME LEVA ISSO AO EXTREMO

Porque:

  • bancos não podem parar;
  • folha não pode falhar;
  • PIX não pode sumir;
  • cartão não pode duplicar;
  • batch não pode atrasar.

Então engenharia enterprise nasce da paranoia operacional.

🔥☕


VERSIONAMENTO — O “TIME MACHINE” CORPORATIVO

Sem versionamento:

  • ninguém sabe quem mudou;
  • ninguém sabe quando;
  • ninguém sabe por quê.

☠️🔥


Mundo moderno

  • Git
  • GitHub
  • GitLab

Mundo mainframe

  • Endevor
  • Changeman
  • Librarian

☕ O CONCEITO É O MESMO

Controlar:

  • mudanças;
  • histórico;
  • rollback;
  • rastreabilidade.

☕💾 ARQUITETURA — O CÉREBRO INVISÍVEL DO SISTEMA

Aqui o júnior normalmente desperta.

Porque descobre que:

sistemas grandes NÃO sobrevivem só com código.

Precisam:

  • organização;
  • integração;
  • escalabilidade;
  • segurança;
  • observabilidade.

Exemplo bancário

Frontend

API Gateway

Microservices

MQ

COBOL/CICS

DB2

Isso é engenharia enterprise.


☠️ MICROservices NÃO SÃO “MÁGICA”

Muita empresa cria:

400 APIs
+
500 containers
+
logs infinitos
+
monitoramento caótico

e chama isso de:

“transformação digital.”

☠️🔥☠️🔥☠️🔥


☕💾 O MAINFRAME ENSINOU ALGO IMPORTANTE

Centralização às vezes é:

  • mais segura;
  • mais simples;
  • mais eficiente.

Por isso muitos core bancários continuam no z/OS.


O GRANDE SEGREDO DA ENGENHARIA DE SOFTWARE

Ela NÃO é sobre tecnologia apenas.

Ela é sobre:

  • reduzir caos;
  • reduzir risco;
  • reduzir falhas;
  • organizar complexidade.

🔥☕


☕ O JÚNIOR QUE EVOLUI RÁPIDO ENTENDE ISSO

Linguagens mudam.

Ontem:

  • COBOL;
  • PL/I;
  • C.

Depois:

  • Java;
  • C#;
  • Python.

Agora:

  • IA assistida;
  • automação;
  • cloud native.

Mas:

  • lógica;
  • arquitetura;
  • qualidade;
  • engenharia;

continuam eternas.


☕💾 O FUTURO DO PROGRAMADOR COBOL

O mercado NÃO quer apenas:

“quem sabe COBOL.”

Quer:

  • APIs;
  • integração;
  • cloud;
  • automação;
  • observabilidade;
  • DevOps;
  • segurança;
  • engenharia moderna.

E AQUI ESTÁ A GRANDE VERDADE

Quem domina:

  • fundamentos enterprise;
  • processamento crítico;
  • arquitetura;
  • mentalidade operacional;

possui vantagem enorme no mercado moderno.

Porque MUITOS desenvolvedores atuais:

  • sabem framework;
  • sabem frontend;
  • sabem cloud;

mas nunca sustentaram:

  • processamento nacional;
  • batch crítico;
  • transações financeiras massivas.

☕💾🔥 CONCLUSÃO — ENGENHARIA DE SOFTWARE É A ARTE DE EVITAR O APOCALIPSE CORPORATIVO 🔥💾☕

Programar faz software funcionar.

Engenharia de software faz:

  • software sobreviver;
  • empresas continuarem operando;
  • sistemas escalarem;
  • produção não explodir às 2h da manhã.

E no fundo…

o mundo mainframe já sabia disso muito antes da internet virar moda. 💾☕🔥


sexta-feira, 29 de novembro de 2024

☕💣 O COBOL NÃO É BAGUNÇA: AS BOAS PRÁTICAS DE CODIFICAÇÃO QUE SEPARAM PROGRAMADORES DE MAINFRAME DE VERDADE DOS MEROS ESCREVEDORES DE CÓDIGO

Bellacosa Mainframe e o clean code no Cobol

☕💣 O COBOL NÃO É BAGUNÇA: AS BOAS PRÁTICAS DE CODIFICAÇÃO QUE SEPARAM PROGRAMADORES DE MAINFRAME DE VERDADE DOS MEROS ESCREVEDORES DE CÓDIGO

Durante décadas, o COBOL carregou uma fama injusta. Muitos profissionais associam a linguagem a programas gigantescos, difíceis de entender, cheios de GO TO, variáveis com nomes estranhos e regras de negócio espalhadas por milhares de linhas.

Mas existe uma verdade que poucos percebem:

O problema nunca foi o COBOL.

O problema sempre foi a forma como algumas pessoas escreveram COBOL.

Quando observamos sistemas modernos desenvolvidos em Enterprise COBOL para z/OS, encontramos recursos avançados, suporte a programação estruturada, funções intrínsecas, XML, JSON, tratamento de exceções e diversas funcionalidades que permitem criar aplicações extremamente organizadas e fáceis de manter.

Neste artigo vamos explorar as principais boas práticas de codificação para COBOL Mainframe, conceitos de Clean Code e técnicas utilizadas pelas equipes mais maduras do mercado.


Por que qualidade de código importa no Mainframe?

Em muitas empresas, um programa COBOL permanece em produção por décadas.

Enquanto uma aplicação web pode ser substituída em poucos anos, não é raro encontrar programas COBOL escritos nos anos 80 ou 90 ainda executando processos críticos.

Isso significa que:

  • O código será lido mais vezes do que escrito.

  • Diversos profissionais irão mantê-lo.

  • A regra de negócio precisa ser compreendida rapidamente.

  • Erros podem gerar impactos milionários.

Portanto, escrever código pensando apenas em "funcionar" é um erro.

O objetivo deve ser:

Funcionar hoje e continuar compreensível daqui a 20 anos.


O princípio mais importante: código deve parecer documentação

Um bom programa COBOL deve ser quase autoexplicativo.

Compare:

Exemplo ruim

IF A = 'S'
   MOVE '1' TO B
END-IF

Agora:

IF CLIENTE-ATIVO
   MOVE STATUS-APROVADO
      TO STATUS-CADASTRO
END-IF

No segundo caso, praticamente não é necessário comentário.

O código descreve o negócio.

Essa é uma das bases do Clean Code.


Utilize nomes significativos

Muitos sistemas antigos utilizam variáveis como:

01 WS-A.
01 WS-B.
01 WS-X.

Isso gera enorme dificuldade de manutenção.

Prefira:

01 WS-SALDO-CONTA.
01 WS-LIMITE-CREDITO.
01 WS-VALOR-SAQUE.

Uma boa regra:

Se o nome não explica o conteúdo, o nome está errado.


Padronize convenções de nomenclatura

Equipes maduras possuem padrões claros.

Exemplo:

WS- = Working Storage
LK- = Linkage
IN- = Entrada
OUT- = Saída
CNT- = Contador
FLG- = Flag

Exemplo:

01 WS-NOME-CLIENTE.
01 WS-IDADE-CLIENTE.
01 FLG-CLIENTE-ATIVO.

A simples leitura permite identificar a finalidade da variável.


Evite GO TO sempre que possível

Durante décadas o GO TO foi utilizado excessivamente.

Exemplo:

IF ERRO
   GO TO 9000-ERRO.

Embora ainda exista em muitos sistemas, o uso excessivo gera:

  • Fluxo confuso

  • Difícil rastreamento

  • Baixa manutenibilidade

Prefira:

IF ERRO
   PERFORM 9000-TRATAR-ERRO
END-IF

O PERFORM torna o fluxo muito mais previsível.


Use terminadores de escopo

Um dos maiores avanços do COBOL moderno foi a introdução dos terminadores explícitos.

Evite:

IF CLIENTE-ATIVO
   IF LIMITE-OK
      MOVE 'S' TO STATUS
ELSE
   MOVE 'N' TO STATUS

Prefira:

IF CLIENTE-ATIVO
   IF LIMITE-OK
      MOVE 'S' TO STATUS
   ELSE
      MOVE 'N' TO STATUS
   END-IF
END-IF

Terminações explícitas eliminam ambiguidades.


Mantenha parágrafos pequenos

Quando um parágrafo possui centenas de linhas, sua manutenção torna-se extremamente difícil.

Ruim:

1000-PROCESSAR.

com 500 linhas.

Melhor:

1000-PROCESSAR.

    PERFORM 1100-VALIDAR-DADOS
    PERFORM 1200-CALCULAR-TAXAS
    PERFORM 1300-ATUALIZAR-SALDOS
    PERFORM 1400-GERAR-RELATORIO.

Cada bloco possui responsabilidade específica.


Uma responsabilidade por parágrafo

Um erro comum é misturar atividades.

Exemplo:

2000-PROCESSAR.

faz:

  • leitura

  • validação

  • cálculo

  • gravação

  • relatório

Tudo junto.

Prefira dividir responsabilidades.

Isso segue o princípio conhecido como:

Single Responsibility Principle (SRP).


Evite código duplicado

Nada gera mais problemas do que duplicação.

Exemplo:

COMPUTE WS-VALOR =
        WS-VALOR * 1.15

copiado em 20 programas diferentes.

Quando a regra mudar, será necessário alterar os 20.

Melhor:

Criar uma rotina centralizada.

CALL 'CALCIMPO'

ou

PERFORM 5000-CALCULAR-IMPOSTO

Centralização reduz erros.


Comentários devem explicar o motivo, não o óbvio

Comentário ruim:

MOVE WS-NOME
 TO WS-NOME-SAIDA

Comentário:

* Move o nome para saída

Isso não agrega valor.

Comentário bom:

* Regra exigida pelo Banco Central
* Circular 3456/2024

Explica o motivo da regra.


Organize o programa em camadas lógicas

Uma estrutura clássica é:

IDENTIFICATION DIVISION

ENVIRONMENT DIVISION

DATA DIVISION

PROCEDURE DIVISION

0000-MAIN

1000-INICIALIZAR

2000-LER-ARQUIVO

3000-PROCESSAR

4000-GRAVAR

9000-FINALIZAR

Essa organização ajuda qualquer programador a navegar rapidamente pelo código.


Utilize COPYBOOKS adequadamente

Copybooks são excelentes para reutilização.

Exemplo:

COPY CLIENTE.

Benefícios:

  • Padronização

  • Reutilização

  • Menor manutenção

Mas cuidado:

Não transforme copybooks em monstros de milhares de linhas.


Trate erros explicitamente

Um programa profissional nunca assume sucesso.

Errado:

READ ARQ-CLIENTE

Melhor:

READ ARQ-CLIENTE
   AT END
      SET FIM-ARQUIVO TO TRUE
END-READ

Ou:

EXEC SQL
    SELECT ...
END-EXEC

IF SQLCODE NOT = ZERO
    PERFORM 9000-TRATAR-ERRO
END-IF

Nunca ignore SQLCODE

Em ambientes DB2 esta regra é sagrada.

Após cada comando SQL:

IF SQLCODE = 0

ou

EVALUATE TRUE
   WHEN SQLCODE = 0
   WHEN SQLCODE = 100
   WHEN OTHER
END-EVALUATE

Ignorar SQLCODE é abrir espaço para falhas silenciosas.


Prefira EVALUATE ao invés de IFs excessivos

Ruim:

IF TIPO = 'A'
...
ELSE
   IF TIPO = 'B'
...

Melhor:

EVALUATE TIPO
   WHEN 'A'
      ...
   WHEN 'B'
      ...
   WHEN 'C'
      ...
   WHEN OTHER
      ...
END-EVALUATE

Mais legível e mais fácil de expandir.


Utilize variáveis booleanas (88 Level)

Um recurso poderoso e subutilizado.

01 WS-STATUS.
   05 WS-COD-STATUS PIC X.

88 CLIENTE-ATIVO VALUE 'A'.
88 CLIENTE-INATIVO VALUE 'I'.

Uso:

IF CLIENTE-ATIVO

Muito melhor que:

IF WS-COD-STATUS = 'A'

Reduza dependências externas

Quanto mais dependências:

  • Mais acoplamento

  • Mais manutenção

  • Mais risco

Sempre avalie:

"Essa chamada realmente é necessária?"


Mantenha consistência visual

Exemplo:

MOVE WS-NOME
   TO WS-NOME-SAIDA

ADD WS-VALOR
   TO WS-TOTAL

PERFORM 3000-PROCESSAR

Código alinhado facilita leitura.

A produtividade da manutenção aumenta significativamente.


Evite números mágicos

Ruim:

IF WS-IDADE > 18

Melhor:

78 IDADE-MINIMA VALUE 18.

IF WS-IDADE > IDADE-MINIMA

A regra fica documentada.


Faça validações no início

Evite processar dados inválidos.

Exemplo:

IF WS-CPF = SPACES
   PERFORM 9000-ERRO
   GO TO 9999-SAIDA
END-IF

Falhar cedo reduz complexidade.


Desenvolva pensando em testes

Uma boa prática moderna é escrever código facilmente testável.

Rotinas menores:

1100-VALIDAR
1200-CALCULAR
1300-GERAR

permitem testes independentes.


Registre logs úteis

Logs não devem apenas indicar erro.

Exemplo:

Cliente 12345 rejeitado.
Motivo: Limite insuficiente.

Informação útil reduz tempo de diagnóstico.


Utilize recursos modernos do COBOL

Muitos programadores ainda escrevem COBOL como nos anos 80.

Entretanto o Enterprise COBOL oferece:

  • Functions

  • Inline Perform

  • Scope Terminators

  • XML PARSE

  • JSON PARSE

  • JSON GENERATE

  • Intrinsic Functions

  • UTF-8

  • National Data

Utilizar recursos modernos aumenta produtividade e legibilidade.


Revise código antes de promover

Code Review é uma das melhores práticas existentes.

Benefícios:

  • Detecta defeitos

  • Padroniza estilo

  • Compartilha conhecimento

  • Melhora qualidade

Nenhum profissional experiente deveria temer revisão.


Métricas que valem a pena acompanhar

Alguns indicadores importantes:

  • Complexidade ciclomática

  • Linhas por módulo

  • Cobertura de testes

  • Duplicação de código

  • Defeitos em produção

O que é medido tende a melhorar.


O verdadeiro significado de Clean Code no Mainframe

Muitos acreditam que Clean Code é apenas uma moda criada para Java ou aplicações web.

Não é.

Clean Code significa:

  • Clareza

  • Simplicidade

  • Legibilidade

  • Manutenibilidade

  • Organização

Esses princípios são universais.

Eles funcionam tão bem em COBOL quanto em qualquer linguagem moderna.


Conclusão

O mercado frequentemente discute modernização de aplicações, APIs, cloud e inteligência artificial. Entretanto, poucas empresas percebem que a maior modernização possível muitas vezes começa dentro do próprio código COBOL.

Um programa limpo reduz custos, diminui defeitos, acelera manutenções e facilita a transferência de conhecimento entre gerações de profissionais.

O COBOL moderno oferece todos os recursos necessários para produzir software elegante, estruturado e sustentável.

A diferença entre um sistema que sobrevive décadas com qualidade e outro que se transforma em um pesadelo operacional não está na linguagem utilizada.

Está na disciplina de engenharia aplicada por quem escreve o código.

E essa disciplina continua sendo uma das habilidades mais valiosas de qualquer profissional de Mainframe.

Título alternativo para maior engajamento em blog/newsletter:

☕💣 SEU COBOL FUNCIONA... MAS ALGUÉM CONSEGUE ENTENDER? AS 25 REGRAS DE CLEAN CODE QUE TODO PROGRAMADOR MAINFRAME DEVERIA SEGUIR ANTES DA PRÓXIMA PROMOÇÃO PARA PRODUÇÃO