Translate

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


Sem comentários:

Enviar um comentário