Como Evoluir Frontend Grande sem Reescrever Tudo

O problema

Frontend grande costuma produzir duas reações ruins.

A primeira:

• conformismo
• ninguém mexe em nada estrutural
• a base vai ficando cada vez mais cansativa

A segunda:

• vontade de reescrever tudo
• migração ampla
• promessa de “agora vai ficar certo”

As duas são perigosas.

No primeiro caso, a dívida só acumula.

No segundo, o time cria um projeto paralelo caro, arriscado e difícil de sustentar junto com o produto real.

Modelo mental

Base grande não melhora por reinício emocional.

Ela melhora por redução progressiva de dor.

Em frase curta:

evoluir frontend grande é melhorar fronteiras e fluxo de mudança aos poucos, sem exigir que o time pare de entregar para “arrumar a casa inteira”.

Isso não significa nunca reescrever nada.

Significa que reescrita ampla deveria ser exceção bem justificada, não reflexo automático de frustração.

Onde normalmente começar

1. Comece pela dor mais cara

Nem toda parte ruim merece atenção agora.

Vale priorizar onde existe:

• bug recorrente
• medo alto de mexer
• acoplamento que trava entrega
• onboarding doloroso
• review lento porque ninguém entende a fronteira

Esse recorte costuma ser melhor do que escolher “o módulo mais feio”.

2. Melhore um fluxo inteiro, não uma estética genérica

Trocar nomes e mover arquivos pode dar sensação de avanço.

Mas o ganho real normalmente aparece quando você melhora um fluxo de ponta a ponta:

• tela
• hooks
• integração
• estado
• fronteira pública

Isso mostra valor rápido e ensina como repetir o padrão depois.

3. Aceite convivência entre velho e novo por um tempo

Quase sempre vai existir fase de transição.

Parte da base ainda segue o modelo antigo.

Parte nova já usa fronteiras melhores.

Isso não é fracasso.

É custo normal de evolução saudável.

O problema é quando o time quer uniformidade instantânea e cria uma migração grande demais para caber na vida real.

Exemplo simples

Imagine um painel administrativo antigo.

Hoje ele sofre com:

• page gigante
• fetch espalhado
• estado duplicado
• componente compartilhado acoplado a domínio

A reação ruim seria abrir uma frente para “migrar toda a arquitetura frontend”.

A reação melhor seria:

1. escolher o fluxo mais crítico, como faturamento
2. separar server state, URL state e UI state com mais clareza
3. reduzir import cruzado
4. deixar components e hooks com papéis melhores
5. usar esse fluxo como novo padrão de referência

Depois disso, o time já ganha:

• exemplo concreto
• vocabulário comum
• menos medo de repetir a abordagem

O papel de anti-corrupção local

Quando a base antiga ainda existe, muitas vezes vale criar uma borda de proteção.

Na prática, isso pode significar:

• wrapper em volta de API antiga
• adaptador entre formato legado e formato novo
• componente de transição
• ponto de entrada mais estável para a feature nova

Isso evita que a parte velha continue contaminando tudo o que nasce depois.

Erros comuns

• Querer resolver a arquitetura inteira em uma única iniciativa.
• Começar pela organização de pasta antes de entender a dor dominante.
• Exigir migração completa antes de colher qualquer ganho local.
• Reescrever sem plano de convivência entre velho e novo.
• Medir sucesso pela beleza da árvore, não pela facilidade de mudar.

Como um senior pensa

Quem já viu reescrita falhar costuma usar um filtro mais pragmático:

• qual dor concreta essa mudança vai reduzir?
• como provar ganho antes de ampliar o escopo?
• como manter entrega enquanto a base evolui?
• qual fronteira nova precisa nascer primeiro?

Esse tipo de pensamento não parece heróico.

Mas normalmente é o que faz a mudança sobreviver.

Ângulo de entrevista

Esse tema aparece em:

• system design frontend
• liderança técnica
• refatoração e legado
• perguntas sobre escala de produto web

Resposta fraca:

eu reestruturaria o frontend e organizaria melhor tudo

Resposta forte:

• escolhe uma dor real
• propõe migração progressiva
• fala de convivência entre modelos
• mostra critério de priorização e redução de risco

É isso que costuma soar mais senior.

Fechando a ideia

Frontend grande quase nunca precisa de uma reescrita épica para começar a melhorar.

Na maioria das vezes, ele precisa de:

• fronteira melhor
• alvo mais claro
• passos menores
• disciplina de convivência

Evoluir sem reescrever tudo não é timidez. Muitas vezes é exatamente o que separa mudança sustentável de teatro arquitetural.