Na rotina do desenvolvimento de software, é comum nos depararmos com demandas que parecem puramente operacionais. A pressão por entregas rápidas muitas vezes empurra a engenharia para o caminho do menor esforço: pegar um código que já funciona em um lugar e replicá-lo em outro. No entanto, questionar o status quo de uma implementação legada pode revelar oportunidades gigantescas de eficiência e economia.
Foi exatamente isso que aconteceu durante um projeto no Banco Itaú. A missão parecia simples: migrar uma funcionalidade já consolidada no portal de Pessoa Física (PF) para o portal de Pessoa Jurídica (PJ). Era o clássico cenário em que um simples "copiar e colar" resolveria a entrega dentro do prazo.
O Diagnóstico: O Custo Invisível do Mainframe
Antes de sair escrevendo código, decidi investigar o comportamento da feature no ambiente de produção do portal PF. Durante a análise de arquitetura e tráfego, notei um padrão ineficiente: o sistema realizava chamadas constantes e automáticas ao Mainframe para buscar dados daquela funcionalidade, independentemente de o usuário final interagir ou não com ela na tela.
Para quem trabalha em ambientes legados ou de alta escala, o consumo de MIPS (Millions of Instructions Per Second) no Mainframe é uma das métricas mais críticas de infraestrutura. Cada requisição desnecessária gera um processamento real que se traduz em custos operacionais altíssimos. O sistema estava gastando recursos de processamento para entregar informações que, na maioria das vezes, nem chegavam a ser visualizadas.
A Ação: Arquitetura Sob Demanda e Proatividade
Em vez de replicar o modelo existente no novo portal, reestruturei a solução para o portal PJ utilizando uma abordagem sob demanda (lazy loading). A lógica foi alterada para que as chamadas ao Mainframe só fossem disparadas no momento exato em que o usuário acionasse a funcionalidade específica na interface.
Percebendo que o problema na origem continuava consumindo recursos desnecessariamente, decidi ir além do escopo inicial da task. Aplicando o princípio da "Regra do Escoteiro" — deixar o código mais limpo do que como você o encontrou —, estendi a melhoria e refatorei a funcionalidade original no portal de Pessoa Física, implementando a mesma estratégia de chamadas sob demanda.
O Resultado: Impacto Mensurável de FinOps
A alteração foi homologada e implantada em produção. Após a validação do deploy, a equipe responsável pelo monitoramento de consumo de infraestrutura e bilhetagem do banco mensurou o impacto da mudança.
A eliminação das chamadas redundantes gerou uma redução drástica no processamento do Mainframe, resultando em uma economia anual estimada de R$ 50 milhões em MIPS.
Lições Aprendidas
Essa experiência reforçou alguns pilares que considero essenciais para qualquer profissional de tecnologia:
- Visão de Negócio e FinOps: Desenvolver software não é apenas fazer a funcionalidade rodar; é entender o impacto financeiro da arquitetura em escala.
- Proatividade além da Task: Limitar-se ao escopo do Jira pode entregar a demanda, mas questionar a solução original é o que gera valor real para a empresa.
- Respeito ao Código Legado, sem Acomodação: Só porque algo está em funcionamento há anos não significa que não possa ser otimizado.
Como você costuma abordar oportunidades de melhoria em códigos legados no seu dia a dia? Já encontrou gargalos parecidos por aí?