 |
| Bellacosa Mainframe o que é divida tecnica |
O que é Dívida Técnica?
Imagine que um banco precisa colocar uma nova funcionalidade em produção até sexta-feira.
O sistema precisa permitir que um cliente solicite um novo tipo de empréstimo.
A equipe percebe que, para fazer tudo corretamente, seriam necessárias três semanas de trabalho.
Mas a diretoria responde:
"Façam funcionar até sexta. Depois melhoramos."
Os desenvolvedores então criam uma solução provisória.
Ela funciona.
Os testes passam.
O cliente fica satisfeito.
Porém...
O código ficou mais difícil de entender, existem duplicações, alguns padrões foram ignorados e a documentação não foi atualizada.
Essa diferença entre o ideal e o que realmente foi entregue é chamada de Dívida Técnica.
Definição simples
A Dívida Técnica é o custo futuro causado por decisões técnicas tomadas para entregar uma solução mais rapidamente ou com menos qualidade do que o ideal.
Assim como uma dívida financeira, ela pode ser útil em situações específicas, mas gera "juros" se não for paga.
Em outras palavras:
É um atalho que economiza tempo hoje, mas aumenta o trabalho amanhã.
Por que o nome "dívida"?
A comparação foi criada pelo programador Ward Cunningham, um dos autores do Manifesto Ágil.
A ideia é simples:
Você "pega emprestado" tempo hoje.
Entrega mais rápido.
Depois precisa "pagar" essa dívida corrigindo o código.
Quanto mais tempo passa, maiores são os "juros".
Uma analogia simples
Imagine comprar uma casa.
Você pode:
construir uma fundação sólida;
usar bons materiais;
fazer tudo corretamente.
Ou pode:
economizar no concreto;
usar materiais mais baratos;
terminar rapidamente.
A casa ficará pronta.
Mas anos depois surgirão:
rachaduras;
infiltrações;
reformas caras.
No software acontece exatamente o mesmo.
Como surge a Dívida Técnica?
Ela aparece quando fazemos escolhas como:
copiar código em vez de reutilizá-lo;
ignorar testes automatizados;
deixar documentação para depois;
não remover código antigo;
usar soluções provisórias como definitivas;
adiar refatorações;
aceitar más práticas por causa do prazo.
Exemplo em COBOL
Imagine um programa de cálculo de juros.
Em vez de criar uma rotina reutilizável, o programador copia o mesmo código para dez programas diferentes.
Hoje parece mais rápido.
Daqui a seis meses, quando a regra mudar, será necessário alterar os dez programas.
Isso é Dívida Técnica.
Outro exemplo
Uma tabela Db2 precisa ser reorganizada.
Como o ambiente está estável, ninguém executa o REORG.
Meses depois:
consultas ficam lentas;
índices crescem;
jobs aumentam de duração.
A manutenção adiada gerou uma dívida operacional que afeta o desempenho.
Exemplo no CICS
Uma transação recebe milhares de acessos.
Para atender ao prazo:
não foi feita análise de performance;
nenhuma otimização foi realizada;
o programa faz leituras repetidas no Db2.
Funciona.
Mas o consumo de CPU cresce diariamente.
Mais uma dívida técnica.
Como ela cresce?
Imagine este ciclo:
Prazo apertado
↓
Solução rápida
↓
Entrega
↓
Código difícil
↓
Mais manutenção
↓
Mais tempo gasto
↓
Nova solução rápida
↓
Mais dívida
Esse ciclo pode durar anos se a dívida nunca for tratada.
Principais tipos de Dívida Técnica
1. Código
duplicação;
complexidade excessiva;
nomes confusos;
falta de modularização.
2. Arquitetura
integração mal planejada;
dependências desnecessárias;
excesso de acoplamento.
3. Banco de Dados
índices inadequados;
tabelas mal modeladas;
ausência de normalização;
consultas ineficientes.
4. Infraestrutura
versões antigas;
bibliotecas desatualizadas;
servidores sem atualização;
configurações improvisadas.
5. Documentação
fluxogramas inexistentes;
requisitos desatualizados;
diagramas incompletos.
6. Testes
pouca cobertura;
testes manuais excessivos;
ausência de testes automatizados.
No Mainframe
A Dívida Técnica pode aparecer em:
programas COBOL gigantes com dezenas de milhares de linhas;
JCLs duplicados;
PROC repetidas;
VSAM mal estruturado;
SQL ineficiente;
índices Db2 inadequados;
transações CICS muito pesadas;
documentação antiga;
rotinas sem comentários;
interfaces MQ improvisadas.
Sinais de alerta
Alguns sintomas indicam que a dívida técnica está crescendo:
cada alteração demora mais;
surgem muitos defeitos após mudanças;
ninguém entende o código;
apenas um especialista consegue manter o sistema;
a documentação está desatualizada;
o desempenho piora constantemente;
há medo de modificar programas antigos.
Como reduzir a Dívida Técnica?
Refatoração
Melhorar o código sem alterar seu comportamento.
Documentação
Atualizar:
requisitos;
fluxogramas;
diagramas;
manuais.
Testes
Criar testes automatizados para reduzir riscos.
Revisão de Código
Outro desenvolvedor analisa o código antes da entrega, identificando problemas e oportunidades de melhoria.
Padronização
Adotar convenções de nomenclatura, arquitetura e desenvolvimento para evitar soluções diferentes para o mesmo problema.
Manutenção preventiva
Reservar tempo em cada projeto para corrigir problemas antigos, em vez de apenas adicionar novas funcionalidades.
Dívida Técnica é sempre ruim?
Não.
Em algumas situações, ela é uma decisão consciente.
Por exemplo:
corrigir rapidamente uma falha crítica em produção;
atender uma exigência legal com prazo curto;
restaurar um serviço essencial após uma indisponibilidade.
Nesses casos, a equipe assume a dívida sabendo que ela será tratada posteriormente.
O problema surge quando ela é esquecida.
Curiosidades
1. Todo sistema possui alguma Dívida Técnica
Mesmo aplicações muito bem desenvolvidas acumulam pequenas dívidas ao longo dos anos.
2. Sistemas Mainframe podem carregar décadas de dívida
É comum encontrar aplicações COBOL criadas nos anos 1980 que receberam centenas de alterações sem uma refatoração completa.
3. Dívida Técnica também afeta infraestrutura
Ela não está apenas no código. Ambientes, automações, documentação e processos também podem acumular dívida.
4. IA ajuda a identificar Dívidas Técnicas
Ferramentas modernas conseguem detectar duplicação de código, funções muito complexas, SQL ineficiente e oportunidades de refatoração.
Erros comuns de iniciantes
"Código antigo é automaticamente Dívida Técnica"
Não.
Um programa COBOL de 30 anos pode ser extremamente bem escrito, documentado e de fácil manutenção.
A idade do código não determina sua qualidade.
"Toda solução rápida é ruim"
Também não.
Uma solução emergencial pode ser a escolha correta, desde que exista um plano para revisá-la depois.
"Só programadores criam Dívida Técnica"
Não.
Analistas, arquitetos, gestores e até decisões de negócio podem contribuir para seu surgimento ao impor prazos irrealistas ou adiar investimentos.
Quando estudar Dívida Técnica?
Depois de aprender:
Lógica de Programação.
Engenharia de Software.
Requisitos.
Análise Funcional.
Arquitetura de Software.
COBOL.
CICS.
Db2.
DevOps e Integração Contínua.
Esse conhecimento ajuda a equilibrar velocidade de entrega e qualidade, evitando que pequenas concessões se transformem em grandes problemas no futuro.
Conclusão
A Dívida Técnica representa o custo futuro gerado por decisões que priorizam rapidez em detrimento da qualidade ideal do software. Em ambientes Mainframe, onde aplicações COBOL, CICS, Db2 e JCL permanecem em produção por décadas, administrar essa dívida é essencial para garantir sistemas estáveis, seguros e de fácil manutenção.
Uma equipe madura não busca eliminar toda dívida técnica, mas sim identificá-la, documentá-la, priorizá-la e reduzi-la continuamente. Assim como uma dívida financeira pode ser administrada com responsabilidade, a dívida técnica também pode ser controlada para que o sistema continue evoluindo sem comprometer a confiabilidade do negócio.
Sem comentários:
Enviar um comentário