Consultoria PJ · 2026
Painel administrativo do ERP
Uma SPA Vue 3 que convive com um MVC legado dentro de um monorepo .NET. Migrei telas por partes, entreguei a gestão de contratos e termos e medi o build antes de otimizá-lo.
- 218commits meus na SPA (~23% do período)
- 223 → 130 sbuild da SPA, em benchmark local
- ~70 → ~38 sjornada de dev no navegador (mediana)
- 68arquivos de teste tocados
O problema
O ERP financeiro é um monorepo grande, com várias gerações convivendo. Tem um MVC histórico em .NET Framework, APIs e hosts em .NET moderno, um console de processamento, bibliotecas compartilhadas e, dentro disso tudo, uma SPA administrativa em Vue 3. Muita gente commita ali ao mesmo tempo: foram mais de 3 mil commits no período em que trabalhei.
Três problemas apareciam juntos:
- Telas importantes ainda viviam no MVC, mas não dava para desligar o legado de uma vez: clientes, rotinas e regras dependiam dele.
- Áreas administrativas novas precisavam nascer na SPA, conversando com serviços que outros fronts também consomem.
- O ciclo de desenvolvimento era lento, e ninguém sabia dizer em qual etapa o tempo ia embora.
O que eu fiz
Migração por partes, não por big bang
Levei uma área do MVC para a SPA sem quebrar quem ainda usava o caminho antigo. A mudança atravessou as camadas:
- redirecionamento no MVC;
- rotas, menu e tipos na SPA;
- gates de migração na camada de negócio compartilhada;
- rotinas compatíveis no back-end em .NET, com testes.
O legado continua de pé enquanto houver consumidor. Cada superfície migra quando está pronta.
Gestão de contratos e termos
Construí a área administrativa para consultar e gerir contratos e o estado de aceite dos termos: telas, entrada no menu, integração com a API e mocks para testar. A capacidade foi liberada por feature flag. A SPA compõe a experiência; quem decide e persiste é o back-end, o mesmo que atende o onboarding.
Um shell com variantes de navegação
Para não duplicar menus e layout a cada variante da SPA, separei três coisas: a escolha da variante, o contrato de navegação (o que cada variante oferece) e um shell visual comum. Assim, uma variante nova da SPA vira configuração, sem copiar o layout inteiro.
Medir antes de otimizar
Antes de mexer em qualquer configuração, criei benchmarks reproduzíveis de três jornadas: subir o ambiente e abrir o app no navegador, gerar o build e rodar os testes. Com os números na mão:
- separei a validação do empacotamento;
- deixei o build sequencial como opção;
- otimizei a configuração do Vite e passei a carregar alguns recursos só quando são usados;
- montei um CI experimental com jobs paralelos e testes divididos em shards.
Build da SPA
SPA + biblioteca de componentes
Jornada de dev no navegador (mediana)
Decisões e trade-offs
Medir jornadas reais, não o tempo percebido. "O build está lento" não diz o que fazer. Benchmark com mesma máquina, mesmos comandos e mediana de várias rodadas diz. O custo é tempo gasto montando o harness antes da primeira otimização.
CI paralelo encurta a espera, mas não é de graça. Jobs independentes terminam antes, só que cada um paga o próprio setup. A espera de quem abriu o PR cai, e os minutos totais de runner podem subir. Por isso o CI ficou como experimento, documentado com esse custo, e não substituiu o pipeline oficial.
Feature flag e migração por superfície. Liberar por etapas reduz o risco, mas deixa dois caminhos vivos por um tempo. Esse custo precisa de dono e de data para acabar.
Shell compartilhado com contrato de navegação. Centralizar evita menus duplicados. O custo é que mudar o contrato exige revisar todas as variantes.
Resultado
Em benchmark local, o build da SPA caiu de 223 s para 130 s, e o build da SPA com a biblioteca de componentes caiu de 246 s para 175 s. A jornada de desenvolvimento no navegador passou de cerca de 70 s para cerca de 38 s, na mediana. São medições locais com amostra pequena, e a proposta ainda está em validação com o time. Não é ganho de produção.
A área migrada e a gestão de contratos e termos estão na SPA, com testes, convivendo com o MVC enquanto ele for necessário.
O que eu faria diferente
Faria cada métrica opcional do benchmark entrar explicitamente no critério de sucesso. Hoje, uma métrica habilitada pode piorar sem reprovar a execução.
Faria o filtro de caminhos do workflow cobrir também as mudanças no host MVC, que podem afetar a SPA.
Antes de propor o CI paralelo como padrão, coletaria uma amostra maior e pareada, comparando a espera e os minutos de runner no mesmo período.