Bellacosa Mainframe e a engenharia de software

☕ Um Café no Bellacosa Mainframe

⚗️ TAKUMI IRUMA E A ALQUIMIA DO SOFTWARE — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE CÓDIGO ERA APENAS UM DOS INGREDIENTES

Engenharia de Software, processos, representações, requisitos, COBOL, qualidade, testes, DevOps, conhecimento, legado, IA — e o dia em que Takumi descobriu que transformar requisitos em código era praticamente alquimia.

🎬 PRÓLOGO — O PROGRAMADOR QUE ACHAVA QUE SOFTWARE ERA CÓDIGO

Takumi Iruma estava diante de sua bancada.

Sobre ela havia alguns materiais aparentemente sem relação:

ferro
madeira
cristais
ervas
água
minério
pedras mágicas

Para uma pessoa comum aquilo era apenas uma pilha de coisas.

Para um alquimista, porém, eram representações intermediárias de alguma coisa que ainda não existia.

Uma espada.

Uma ferramenta.

Uma poção.

Uma carroça.

Uma casa.

Talvez até aquele lendário vaso sanitário mágico que prova definitivamente que, mesmo em outro mundo, infraestrutura sanitária continua sendo requisito não funcional importantíssimo.

Em algum datacenter distante, nosso jovem programador COBOL observava outra bancada.

Sobre ela estavam:

requisitos
diagramas
copybooks
programas COBOL
JCL
DDL
casos de teste
documentação
logs
procedimentos

Ele olhou aquilo e perguntou:

— Mestre Takumi, onde está o software?

Takumi apontou para tudo.

— Aí.

— Não, mestre. Quero dizer o programa.

Takumi sorriu.

— Esse é seu primeiro erro.

E assim começou nossa dungeon.

🏭 CAPÍTULO 1 — SOFTWARE É UM PRODUTO

Uma das grandes mudanças introduzidas pela Engenharia de Software foi tratar software como produto.

Parece óbvio hoje.

Mas essa mudança conceitual possui consequências profundas.

Nos primeiros tempos da computação era muito fácil associar:

SOFTWARE = PROGRAMA

O programador recebia uma necessidade, escrevia código, compilava e executava.

Se o compilador dissesse:

MAXCC=0000

havia uma grande tentação de declarar:

Funcionou!

Só que compilação bem-sucedida significa basicamente que o programa conseguiu atravessar determinadas verificações necessárias àquela etapa.

Não significa que o sistema resolve corretamente o problema.

Observe:

COMPUTE WS-JUROS =
        WS-SALDO * WS-TAXA.

Sintaticamente, isso pode estar perfeito.

Agora pergunte:

Qual é a taxa?
Ela é mensal ou anual?
É percentual ou decimal?
Quem determina seu valor?
Existe arredondamento?
Qual legislação rege o cálculo?
O cálculo deve ser auditável?
Devemos registrar a taxa utilizada?
Existe uma data de vigência?
O que acontece quando a taxa é zero?
Taxas negativas são possíveis?
Quem pode alterar essa informação?

Nosso pequeno COMPUTE acabou de abrir uma dungeon inteira.

Takumi coloca uma barra de ferro sobre a mesa.

— Isto é uma espada?

— Não.

— E seu programa COBOL isolado também não é necessariamente o produto completo.

📦 CAPÍTULO 2 — O PRODUTO SOFTWARE É MAIOR QUE O SOURCE

Imagine um sistema bancário em mainframe.

O iniciante encontra:

PGMCRD01.CBL

e pensa:

Achei o sistema.

Não necessariamente.

O verdadeiro produto talvez envolva:

COBOL
copybooks
JCL
PROCs
BMS Maps
Db2
DDL
VSAM
CICS definitions
parâmetros
interfaces
mensageria
documentação
casos de teste
dados de teste
procedimentos operacionais
runbooks
monitoramento
logs
controles de segurança

Portanto:

SOFTWARE ≠ APENAS SOURCE CODE

Uma representação melhor seria:

PRODUTO DE SOFTWARE
        =
CÓDIGO
+
DADOS
+
CONFIGURAÇÃO
+
DOCUMENTAÇÃO
+
TESTES
+
CONHECIMENTO OPERACIONAL
+
PROCEDIMENTOS
+
EVIDÊNCIAS

Isso explica algo curioso encontrado frequentemente em sistemas legados.

Uma empresa pode possuir:

100% do source code

e talvez apenas:

60% do conhecimento necessário

para compreender plenamente o sistema.

Os outros 40% estavam na cabeça de Antônio, que se aposentou em 2007.

Ou de Maria, que sabia por que determinado job precisava executar antes das 03:17.

Ou de Joaquim, que lembrava por que aquele campo aparentemente inútil do copybook jamais poderia ser removido.

O código permaneceu.

Parte do conhecimento desapareceu.

🧠 CAPÍTULO 3 — TAKUMI DESCOBRE QUE SOFTWARE É CONHECIMENTO

Aqui encontramos uma das ideias mais interessantes discutidas nesta nossa aventura.

Uma forma poderosa de compreender Engenharia de Software é enxergar desenvolvimento como um processo de criação e manipulação de representações.

Imagine um banco dizendo:

Queremos permitir que clientes solicitem aumento do limite do cartão.

Isso já representa conhecimento.

Mas ainda é extremamente abstrato.

Podemos transformá-lo:

NECESSIDADE
     ↓
REQUISITO
     ↓
MODELO
     ↓
ARQUITETURA
     ↓
DESIGN
     ↓
PROGRAMA
     ↓
EXECUTÁVEL
     ↓
TESTES
     ↓
PRODUÇÃO

Observe o detalhe.

Não estamos necessariamente criando coisas completamente independentes.

Estamos descrevendo progressivamente o mesmo sistema através de diferentes representações.

Takumi pega minério.

Transforma em metal.

Transforma o metal em lâmina.

Transforma a lâmina em espada.

O programador faz algo semelhante:

IDEIA
 ↓
REQUISITO
 ↓
MODELO
 ↓
ALGORITMO
 ↓
COBOL
 ↓
LOAD MODULE

É a alquimia da Engenharia de Software.

⚗️ CAPÍTULO 4 — O PROGRAMADOR É UM ALQUIMISTA DE REPRESENTAÇÕES

Imagine a seguinte regra:

Clientes inadimplentes há mais de 90 dias não podem solicitar aumento do limite.

O programador transforma isso em:

IF WS-DIAS-ATRASO > 90
    MOVE 'N' TO WS-PERMITE-AUMENTO
END-IF.

Acabamos de realizar uma transformação:

CONHECIMENTO DO NEGÓCIO
          ↓
REPRESENTAÇÃO COMPUTACIONAL

Parece simples.

Mas existe uma armadilha.

O requisito dizia:

mais de 90 dias

Portanto:

> 90

Mas alguém poderia programar:

IF WS-DIAS-ATRASO >= 90

Agora clientes exatamente no nonagésimo dia foram incluídos.

Um caractere mudou uma regra empresarial.

Esse pequeno exemplo mostra por que transformar representações é perigoso.

Toda transformação pode introduzir:

erro
omissão
ambiguidade
interpretação
inconsistência

É exatamente por isso que Engenharia de Software precisa de mecanismos de avaliação.

🏰 CAPÍTULO 5 — AS DUAS GRANDES PEÇAS DA DUNGEON

Podemos simplificar o processo de desenvolvimento em duas grandes categorias:

PROCESSO DE DESENVOLVIMENTO
          |
     +----+----+
     |         |
ATIVIDADES  REPRESENTAÇÕES

As representações armazenam conhecimento sobre o sistema.

As atividades criam, modificam, examinam ou controlam essas representações.

Essa ideia é particularmente elegante porque não depende de religião metodológica.

Você pode trabalhar com:

Waterfall
Scrum
Kanban
XP
DevOps
SAFe
CI/CD

Pode programar em:

COBOL
PL/I
Assembler
Java
Python
JavaScript

O princípio continua existindo.

Estamos criando, transformando, avaliando e controlando representações.

🧭 CAPÍTULO 6 — PRIMEIRA ATIVIDADE: LEVANTAMENTO DE INFORMAÇÕES

Antes de fabricar alguma coisa, Takumi precisa entender o problema.

O mesmo vale para software.

Levantamento de informações significa adquirir conhecimento externo necessário ao desenvolvimento.

Pode significar conversar com:

usuários
analistas
especialistas
DBAs
auditores
operações
segurança
arquitetos
gestores
clientes

Mas no mainframe existe uma variante maravilhosa.

Às vezes ninguém sabe a resposta.

Então começa a arqueologia.

Você examina:

programas COBOL
copybooks
JCL
PROCs
tabelas Db2
arquivos VSAM
CICS
mensagens
logs
SMF
documentação antiga
tickets
incidentes

E encontra:

IF WS-COD-PAIS = 076
    PERFORM 4200-TRATA-BRASIL
END-IF.

Por quê?

Ninguém sabe.

O programador iniciante pensa:

Código velho.

O programador experiente pensa:

Evidência arqueológica.

Antes de apagar, investigue.

👻 CAPÍTULO 7 — O CONHECIMENTO TRIBAL

Existe uma frase particularmente perigosa em informática:

Sempre foi assim.

Imagine um batch.

JOB A
 ↓
JOB B
 ↓
JOB C

JOB B sempre executa às 03:17.

Você pergunta por quê.

Um operador responde:

— Porque precisa ser assim.

— Mas por quê?

— O Carlos sabia.

— Onde está Carlos?

— Aposentou-se em 2014.

Parabéns.

Você encontrou conhecimento tribal.

O sistema possui uma regra que não está adequadamente representada em documentação, código compreensível ou procedimento formal.

Ela existe na memória humana.

Quando a pessoa vai embora:

CONHECIMENTO
     |
     V
 /DEV/NULL

Esse fenômeno conecta Engenharia de Software a outro conceito importante:

Bus Factor.

Quantas pessoas precisam desaparecer inesperadamente antes que determinado conhecimento crítico seja perdido?

Se a resposta for:

Takumi recomenda fabricar imediatamente uma poção de documentação.

🔄 CAPÍTULO 8 — SEGUNDA ATIVIDADE: MUDANÇA DE REPRESENTAÇÃO

Grande parte do desenvolvimento é transformação.

Observe:

CONVERSA
   ↓
REQUISITO
   ↓
MODELO
   ↓
ESPECIFICAÇÃO
   ↓
CÓDIGO
   ↓
EXECUTÁVEL

O compilador também transforma representações.

Você escreve:

ADD WS-VALOR TO WS-TOTAL.

Aquilo passa por diversas transformações até resultar em instruções executáveis pela máquina.

Integração moderna faz exatamente a mesma coisa.

Imagine:

Aplicativo
   ↓
JSON
   ↓
REST
   ↓
z/OS Connect
   ↓
COBOL/CICS
   ↓
Db2

Cada fronteira representa uma transformação ou interpretação de informação.

É por isso que modernização não significa necessariamente eliminar o legado.

Muitas vezes significa criar novas representações e interfaces para capacidades existentes.

🔎 CAPÍTULO 9 — TERCEIRA ATIVIDADE: AVALIAÇÃO

Takumi terminou uma espada.

Ele não simplesmente entrega a espada.

Verifica:

resistência
peso
equilíbrio
acabamento
finalidade

Software também precisa ser avaliado.

Daí surgem:

code review
teste unitário
teste integrado
teste de sistema
UAT
regressão
análise estática
testes de performance
testes de segurança

No ecossistema mainframe podemos encontrar ferramentas e práticas envolvendo:

ZUnit
COBOL Check
pipelines
análise estática
automação de testes

Mas existe uma distinção conceitual importantíssima.

Verificação

Pergunta:

Construímos corretamente?

Validação

Pergunta:

Construímos a coisa correta?

É perfeitamente possível produzir um sistema:

bem programado
bem documentado
sem warnings
com testes aprovados

e que resolve o problema errado.

Temos então:

MAXCC=0000

para o desastre.

🧠 CAPÍTULO 10 — QUARTA ATIVIDADE: REFLEXÃO

Esta é uma atividade extremamente interessante.

Reflexão significa pensar sobre o problema, as soluções e as próprias representações que construímos.

Imagine encontrar:

IF WS-FLAG = 'S'
    PERFORM 8500-PROCESSA
END-IF.

Você pergunta:

O que é WS-FLAG?

Começa a investigação.

Procura referências.

Consulta o copybook.

Examina o programa chamador.

Pesquisa documentação.

Analisa histórico.

Conversa com alguém.

Descobre finalmente que aquilo implementa uma regra criada após um incidente ocorrido em 1998.

O código ganhou significado.

Você não mudou necessariamente nenhuma linha.

Mesmo assim realizou trabalho de Engenharia de Software.

Você produziu conhecimento.

É por isso que manutenção de legado frequentemente parece arqueologia.

🎛️ CAPÍTULO 11 — QUINTA ATIVIDADE: CONTROLE

Takumi possui dezenas de objetos na oficina.

Imagine se ninguém soubesse:

quem criou
quando criou
qual material utilizou
qual versão é atual
quem aprovou
onde será usado

Teríamos caos.

Em software temos o mesmo problema.

Precisamos responder:

Quem alterou?
Por quê?
Quando?
Qual versão?
Qual requisito?
Quem aprovou?
Quais testes passaram?
O que foi implantado?
Como voltar?

Daí surgem ferramentas e processos como:

Git
Endevor
Changeman
ISPW
Jenkins
DBB
pipelines
change management
aprovações
segregação de funções

O iniciante às vezes chama isso de burocracia.

Até acontecer um incidente.

Então alguém pergunta:

Quem colocou isso em produção?

Silêncio.

Nesse momento, versionamento deixa de parecer burocracia e passa a parecer magia ancestral de proteção.

📐 CAPÍTULO 12 — QUALIDADE NÃO É UMA POÇÃO JOGADA NO FINAL

Existe uma ideia que precisa ser destruída:

DESENVOLVIMENTO
     ↓
TESTE
     ↓
QUALIDADE

Como se qualidade pudesse ser adicionada depois.

Não pode.

Imagine:

REQUISITO ERRADO
      ↓
DESIGN CORRETO
      ↓
PROGRAMA CORRETO
      ↓
TESTE CORRETO

Resultado?

Sistema errado.

Todos fizeram corretamente aquilo que lhes foi pedido.

Esse é o terror.

Portanto:

QUALIDADE
   |
   +-- requisitos
   +-- arquitetura
   +-- design
   +-- código
   +-- testes
   +-- implantação
   +-- operação
   +-- manutenção

Qualidade é uma propriedade construída durante o processo.

Não uma inspeção final.

🏭 CAPÍTULO 13 — SOFTWARE É INDÚSTRIA, MAS NÃO É PARAFUSO

A analogia entre desenvolvimento de software e produção industrial trouxe enorme quantidade de conhecimento útil.

Processos.

Controle.

Qualidade.

Padronização.

Medição.

Rastreabilidade.

Melhoria contínua.

Mas precisamos reconhecer uma diferença fundamental.

Uma fábrica transforma:

AÇO
 ↓
PEÇA
 ↓
COMPONENTE
 ↓
AUTOMÓVEL

Software transforma principalmente:

CONHECIMENTO
 ↓
REQUISITO
 ↓
MODELO
 ↓
ALGORITMO
 ↓
CÓDIGO
 ↓
COMPORTAMENTO COMPUTACIONAL

Existe outra diferença econômica fascinante.

Fabricar o segundo automóvel continua consumindo matéria-prima.

Copiar um executável custa praticamente nada comparado ao esforço necessário para criá-lo.

O verdadeiro custo está em:

entender
descobrir
projetar
implementar
testar
corrigir
operar
manter
evoluir

Portanto software é um produto industrial peculiar.

Sua principal matéria-prima é conhecimento.

🚀 CAPÍTULO 14 — AGILE NÃO MATOU ESSA IDEIA

Alguns poderiam olhar para representações, documentação e processos e pensar:

Isso é Waterfall.

Não.

Agile mudou principalmente como organizamos e conduzimos o desenvolvimento.

As representações continuam existindo.

Uma user story é representação.

Um backlog é representação.

Um source é representação.

Um teste automatizado é representação.

Um commit é representação.

Um arquivo YAML é representação.

Uma especificação OpenAPI é representação.

Infrastructure as Code é representação.

Até um dashboard representa alguma coisa:

COMPORTAMENTO REAL DO SISTEMA
            ↓
MÉTRICAS
            ↓
DASHBOARD

DevOps também não elimina essa teoria.

Na realidade, automatiza uma quantidade enorme de transformações e avaliações.

🤖 CAPÍTULO 15 — TAKUMI ENCONTRA A PEDRA FILOSOFAL DA IA

Agora chegamos a 2026.

O programador entrega um COBOL para uma IA:

Explique este programa.

Temos:

COBOL
 ↓
LLM
 ↓
DOCUMENTAÇÃO

Mudança de representação.

Depois:

Gere testes para este requisito.

REQUISITO
 ↓
LLM
 ↓
CASOS DE TESTE

Depois:

Explique este copybook.

COPYBOOK
 ↓
LLM
 ↓
MODELO CONCEITUAL

Depois:

Crie uma interface JSON.

ESTRUTURA LEGADA
       ↓
      IA
       ↓
ESTRUTURA MODERNA

Aí percebemos algo fascinante.

IA generativa pode ser vista como uma poderosa máquina de transformação de representações.

Mas existe uma enorme pegadinha.

Transformar não significa preservar perfeitamente o conhecimento.

Uma IA pode:

omitir
interpretar
inventar
generalizar
simplificar

Portanto, as outras atividades continuam necessárias.

Especialmente:

AVALIAÇÃO
REFLEXÃO
CONTROLE

A IA não aboliu Engenharia de Software.

Ela tornou Engenharia de Software ainda mais necessária.

💥 CAPÍTULO 16 — A ALQUIMIA PROIBIDA

Takumi encontra uma fórmula perigosa:

REQUISITO RUIM
      +
AUTOMAÇÃO
      +
VELOCIDADE
      =
ERRO EM ESCALA

Antes, um programador poderia produzir cinco artefatos errados.

Agora uma IA pode produzir cinquenta em minutos.

Código.

Testes.

Documentação.

APIs.

Scripts.

Casos de teste.

Diagramas.

Tudo perfeitamente consistente...

...com uma premissa errada.

É quase bonito.

E aterrorizante.

A produtividade aumenta a importância da validação.

Quanto maior nossa capacidade de produzir, maior precisa ser nossa capacidade de verificar o que estamos produzindo.

🧪 CAPÍTULO 17 — TAKUMI FABRICA UM SISTEMA DO ZERO

Vamos acompanhar um exemplo completo.

O banco informa:

Depois de três tentativas consecutivas de PIN incorreto, bloqueie o cartão.

Temos nossa primeira representação.

Takumi imediatamente pergunta:

— Três tentativas onde?

Boa pergunta.

Começamos a refletir:

São consecutivas?
Existe janela temporal?
PIN correto zera o contador?
Vale em qualquer ATM?
Tentativas no POS contam?
Bloqueio é permanente?
Existe desbloqueio automático?
Precisamos registrar os eventos?

O requisito aparentemente simples explode.

Após investigação:

Após três tentativas consecutivas de PIN inválido, independentemente do ATM utilizado, o cartão deverá ser bloqueado. Uma autenticação válida antes da terceira tentativa reinicia o contador.

Agora temos representação melhor.

Criamos dados:

PIN-ERROR-COUNT
CARD-STATUS
LAST-ATTEMPT

Criamos COBOL:

IF PIN-INVALID
    ADD 1 TO PIN-ERROR-COUNT

    IF PIN-ERROR-COUNT >= 3
        MOVE 'B' TO CARD-STATUS
    END-IF
ELSE
    MOVE ZERO TO PIN-ERROR-COUNT
END-IF.

Agora avaliamos.

CONTADOR  EVENTO       RESULTADO

0         erro         1
1         erro         2
2         erro         3 / bloqueio
2         correto      0

Depois precisamos controlar a mudança:

commit
 ↓
review
 ↓
build
 ↓
teste
 ↓
aprovação
 ↓
deploy
 ↓
monitoramento

Perceba a sequência.

Nunca estivemos simplesmente "programando COBOL".

Estávamos transformando conhecimento até torná-lo comportamento computacional controlado.

🏛️ CAPÍTULO 18 — O MAINFRAME COMO MUSEU VIVO DO CONHECIMENTO

Mainframes fornecem talvez um dos melhores laboratórios para compreender essa teoria.

Imagine um programa criado em 1987.

Recebe alterações em:

Aquele programa contém mais do que algoritmos.

Ele pode carregar vestígios de:

mudanças monetárias
legislação
fusões
novos produtos
novas regulamentações
incidentes
mudanças arquiteturais
migrações
restrições técnicas
decisões comerciais

Um programa COBOL antigo pode ser um fóssil executável da organização.

Por isso aquela rotina estranha talvez não seja lixo.

Talvez seja história empresarial compilada.

Antes de remover:

PERFORM 7310-ROTINA-ESTRANHA

descubra por que ela existe.

Takumi jamais jogaria fora um cristal desconhecido encontrado numa dungeon antes de descobrir suas propriedades.

O mantenedor de legado deveria desenvolver o mesmo instinto.

🗿 CAPÍTULO 19 — AS 80 COLUNAS E O FANTASMA DOS CARTÕES

Existe um easter egg histórico maravilhoso aqui.

COBOL herdou convenções relacionadas aos cartões perfurados de 80 colunas.

O cartão físico desapareceu.

Mas durante décadas continuamos encontrando vestígios daquela representação.

Observe a cadeia:

CARTÃO FÍSICO
      ↓
80 COLUNAS
      ↓
FORMATO DO SOURCE
      ↓
CONVENÇÃO
      ↓
LEGADO

O objeto desapareceu.

A representação sobreviveu.

Isso ensina uma coisa fantástica sobre sistemas:

decisões técnicas podem sobreviver às razões que originalmente as criaram.

Quando alguém perguntar por que determinado sistema funciona daquela maneira, talvez a resposta esteja vinte, trinta ou cinquenta anos no passado.

🧰 CAPÍTULO 20 — CHECKLIST DO APRENDIZ DE ALQUIMISTA COBOL

Quando receber uma alteração, não abra imediatamente o editor.

Primeiro pergunte:

1. Qual problema estamos resolvendo?

Depois:

2. Quem conhece a regra?

Então:

3. Onde esse conhecimento está representado hoje?

Pode estar em:

documentação
COBOL
JCL
copybook
Db2
VSAM
ticket
procedimento
cabeça de alguém

Depois identifique:

4. Quais representações serão afetadas?

Não pense apenas no programa.

Talvez precise alterar:

copybook
programa
DDL
JCL
API
teste
documentação
monitoramento

Então pergunte:

5. Como validaremos a transformação?

Crie evidências.

Depois:

6. Como controlaremos a mudança?

Versionamento.

Aprovação.

Deploy.

Rollback.

Finalmente:

7. Como o próximo programador entenderá isso daqui a cinco anos?

Essa última pergunta separa frequentemente uma correção rápida de Engenharia de Software profissional.

🧙 CAPÍTULO 21 — O COMENTÁRIO QUE SALVA O FUTURO

Imagine encontrar:

*> ALTERADO EM 25/09/2026
*> MOTIVO: REGRA XYZ
*> CHAMADO: INC-12345
*> AUTOR: USER-ID

Daqui a dez anos talvez ninguém conheça o autor.

Mas existe uma pista.

O comentário tornou-se representação de conhecimento histórico.

Não precisamos transformar programas em romances.

Mas registrar:

quem
quando
por quê
referência

pode economizar horas de arqueologia futura.

Software possui memória.

Nós decidimos quanto dela sobreviverá.

⚔️ CAPÍTULO 22 — O VERDADEIRO INIMIGO NÃO É O LEGADO

Chegamos então a outra conclusão.

Legado não significa simplesmente:

velho

Um sistema antigo pode ser:

estável
conhecido
testado
auditado
rentável
crítico

E um microsserviço criado ontem pode já ser legado se ninguém consegue entendê-lo.

O verdadeiro problema é conhecimento perdido.

Quando existe:

código sem contexto
regra sem origem
interface sem contrato
job sem explicação
dependência sem documentação

temos dívida de conhecimento.

Modernização séria precisa recuperar esse conhecimento antes de simplesmente trocar tecnologias.

Caso contrário:

COBOL incompreendido
       ↓
Java incompreendido

Parabéns.

Gastamos milhões para modernizar a linguagem do problema.

O problema permaneceu.

🏆 CAPÍTULO 23 — O QUE SIGNIFICA SER PROFISSIONAL

Voltamos finalmente ao ponto inicial.

Software tornou-se atividade profissional não simplesmente porque utilizamos metodologias sofisticadas.

Profissionalização significa tornar o processo:

compreensível
controlável
avaliável
repetível
auditável
evolutivo

Um cliente maduro não deveria perguntar somente:

Vocês sabem COBOL?

Deveria perguntar:

Como vocês desenvolvem?

Como levantam requisitos?

Como controlam versões?

Como testam?

Como tratam defeitos?

Como rastreiam mudanças?

Como garantem segurança?

Como documentam decisões?

Como fazem rollback?

Como medem qualidade?

Como preservam conhecimento?

Essas perguntas revelam a capacidade real de uma organização muito melhor do que uma apresentação cheia de palavras mágicas.

⚗️ EPÍLOGO — TAKUMI ENTREGA A POÇÃO

Nosso aprendiz finalmente volta à oficina.

Sobre a bancada está o programa COBOL.

Ele pergunta:

— Mestre, agora entendi. Então COBOL não é software?

Takumi balança a cabeça.

— É parte dele.

— E documentação?

— Também.

— Testes?

— Também.

— Dados?

— Também.

— JCL?

— Infelizmente também.

Takumi sorri.

O aprendiz continua:

— Então o que fazemos durante o desenvolvimento?

Takumi coloca cinco cristais sobre a mesa:

INFORMAÇÃO
TRANSFORMAÇÃO
AVALIAÇÃO
REFLEXÃO
CONTROLE

E finalmente explica:

Pegamos conhecimento sobre um problema e progressivamente o transformamos em representações capazes de produzir um comportamento computacional confiável.

O aprendiz olha novamente para:

IDENTIFICATION DIVISION.

Agora aquilo parece diferente.

Não é simplesmente o começo de um programa.

É uma representação.

Uma entre muitas.

Antes dela houve conversas, regras, necessidades e decisões.

Depois dela haverá compilação, testes, execução, logs, manutenção e novas alterações.

E talvez daqui a quarenta anos outro programador encontre aquele source.

Se fizermos nosso trabalho direito, ele conseguirá descobrir não apenas o que o programa faz, mas por que ele existe.

Essa talvez seja uma das responsabilidades menos comentadas da Engenharia de Software.

Nós não escrevemos somente para computadores.

Escrevemos para pessoas que ainda nem chegaram.

☕ ÚLTIMO CAFÉ NO BELLA COSA MAINFRAME

O iniciante aprende:

COBOL

Depois aprende:

CICS
Db2
VSAM
JCL

Mais tarde descobre arquitetura.

Depois qualidade.

Depois processos.

Depois negócio.

Depois pessoas.

Até perceber que passou a carreira inteira trabalhando com algo invisível:

conhecimento.

COBOL é uma representação desse conhecimento.

Java é outra.

UML é outra.

JSON é outra.

OpenAPI é outra.

JCL é outra.

Um teste é outra.

Uma pipeline é outra.

Um prompt para uma IA também é outra.

As tecnologias mudam.

As representações mudam.

As ferramentas mudam.

Os nomes das metodologias mudam.

Mas permanece o grande desafio:

PROBLEMA HUMANO
      ↓
CONHECIMENTO
      ↓
REPRESENTAÇÕES
      ↓
TRANSFORMAÇÕES
      ↓
AVALIAÇÃO
      ↓
SOFTWARE
      ↓
RESULTADO

É por isso que Engenharia de Software nunca foi simplesmente saber programar.

E é por isso que uma IA capaz de gerar dez mil linhas de código em minutos não elimina o engenheiro.

Ela apenas constrói uma máquina alquímica muito mais rápida.

Alguém ainda precisa saber:

o que colocar nela, o que deveria sair dela e como descobrir se a poção resultante vai curar o usuário ou explodir a dungeon inteira.

Takumi fecha a oficina.

O programador olha para o último job da noite.

IEF142I JOB01742 STEP030 - STEP WAS EXECUTED - COND CODE 0000

Ele sorri.

Antigamente teria ido embora satisfeito.

Agora sabe que ainda falta uma pergunta:

MAXCC=0000... mas construímos a coisa certa?

No relógio do datacenter:

03:17.

Em algum lugar, um velho batch começa a executar.

Ninguém sabe exatamente por quê.

Ainda.

☕ Bem-vindo à Engenharia de Software.

Translate

terça-feira, 11 de dezembro de 2018