Como você decide quando refatorar versus reescrever um sistema do zero?

Question

Accepted Answer

Por padrão, **refatore**. Uma reescrita só se justifica quando o sistema existente não consegue mais evoluir para atender aos requisitos a um custo aceitável, e você consegue continuar entregando valor enquanto a faz. A maioria dos instintos de "precisamos de uma reescrita" é na verdade um problema de tech debt não gerenciado que a refatoração incremental resolve com muito menos risco.

## Como raciocino sobre isso

- **A arquitetura central ainda é viável?** Se o modelo de dados, as fronteiras e o runtime conseguem se esticar para os novos requisitos, refatore. Se as premissas fundamentais estão erradas (paradigma de armazenamento errado, sem forma de escalar, fim de vida da linguagem/plataforma), uma reescrita vira uma candidata real.
- **Qual é a frequência de mudança?** Código que raramente muda não precisa ser bonito. Concentre o esforço onde o time trabalha diariamente.
- **Entendemos o comportamento atual?** Uma reescrita joga fora anos de conhecimento codificado sobre casos extremos. Se não há testes nem especificação, uma reescrita reintroduzirá bugs antigos.

## Um framework de decisão

| Sinal | Tender a refatorar | Tender a reescrever |
| --- | --- | --- |
| Arquitetura atende aos requisitos | Sim | Não |
| Cobertura de testes/spec | Baixa ou alta | Alta o bastante para verificar paridade |
| Pode entregar incrementalmente | Sim | Difícil, big-bang |
| Time entende o código | Sim | Não, e os autores originais saíram |

## Trade-offs

- **Refatorar:** menor risco, entrega contínua, mas lento sobre uma fundação realmente apodrecida.
- **Reescrever:** folha em branco, mas você paga um **imposto de congelamento de features**, carrega o **custo de manutenção dupla** e arrisca a clássica armadilha de over-engineering do segundo sistema.
- Prefira o caminho intermediário do **strangler-fig**: erga o novo sistema ao lado do antigo, roteie o tráfego incrementalmente, delete o antigo peça por peça. Isso oferece os benefícios da reescrita com o risco de uma refatoração.

## Armadilhas

- Reescrever por razões **estéticas ou movidas por currículo**, não por custo de negócio.
- Subestimar o comportamento oculto; sempre caracterize o comportamento atual com testes primeiro.
- Uma reescrita big-bang de vários trimestres que não entrega nada — momentum e confiança ambos desmoronam.

## Por que isso importa

A decisão de refatorar vs. reescrever é uma das decisões de maior alavancagem que um Tech Lead toma. Erre para o lado da reescrita e você pode congelar a entrega por um ano e ainda assim falhar; erre para o lado da refatoração e você sangra velocidade lentamente. Enquadrá-la como uma decisão de custo e risco, não de gosto, é o que separa o julgamento sênior da preferência.

Sinal	Tender a refatorar	Tender a reescrever
Arquitetura atende aos requisitos	Sim	Não
Cobertura de testes/spec	Baixa ou alta	Alta o bastante para verificar paridade
Pode entregar incrementalmente	Sim	Difícil, big-bang
Time entende o código	Sim	Não, e os autores originais saíram