Reescrever do zero ou evoluir o sistema atual

Reescrever um sistema do zero é a decisão mais cara que uma empresa toma sobre software, e é tomada com frequência pelo motivo errado: desconforto com um código que ninguém entende mais. Antes de decidir, é preciso separar dois problemas diferentes, o sistema não faz o que o negócio precisa e o código é desagradável de mexer. Só o primeiro justifica reescrita.

Os quatro motivos que justificam reescrever

A arquitetura impede o que o negócio precisa. Não "dificulta", impede. Exemplos concretos: o sistema foi feito para um cliente único e agora precisa isolar dados de vários clientes; o banco não suporta o volume atual e a estrutura de dados não permite particionamento; a aplicação é monolítica de tal forma que não é possível escalar a única parte que recebe carga.

A plataforma perdeu suporte de segurança. Uma versão de linguagem ou framework sem atualização de segurança é risco real, não estético. Se não existe caminho de atualização gradual, a reescrita passa a ser obrigação.

Não existe quem mantenha. Tecnologia sem profissionais disponíveis no mercado é um problema de continuidade. Aqui o critério é objetivo: você consegue contratar alguém para mexer nisso em prazo razoável e a preço de mercado?

O custo de manutenção superou o de reconstrução. Quando cada alteração pequena leva semanas e quebra outras três coisas, o sistema já está sendo pago em parcelas. Meça: quantas horas por mês são gastas apenas mantendo o que existe funcionando?

Os motivos que não justificam

• "O código é feio." Feio e funcionando vale mais que bonito e por fazer.
• "A tecnologia é antiga." Antiga com suporte ativo é diferente de obsoleta. Sistemas rodando há dez anos em plataformas maduras costumam ser os mais estáveis da empresa.
• "O time novo não gosta." Legítimo como preferência, insuficiente como investimento.
• "Vamos aproveitar e modernizar." Reescrita motivada por oportunidade, e não por impedimento, é a que mais estoura prazo.

O que a reescrita costuma custar a mais do que o previsto

O motivo pelo qual reescritas estouram é sempre o mesmo: o sistema antigo contém regras de negócio que ninguém documentou. Aquele tratamento estranho para um tipo de cliente, aquela exceção de arredondamento, aquele campo que só é obrigatório em uma situação. Essas regras foram aprendidas ao longo de anos, custaram dinheiro para descobrir e só reaparecem quando algo quebra em produção no sistema novo.

Some a isso:

• Congelamento de evolução. Durante a reescrita, o negócio não para de mudar, mas o sistema fica parado. Você paga duas vezes: o time novo constrói e o time antigo continua ajustando o que está no ar.
• Migração de dados. Trazer histórico sujo, com formatos inconsistentes e duplicidade, costuma equivaler a um módulo inteiro.
• Reaprendizado dos usuários. Processo interrompido, treinamento, produtividade menor por semanas.

Comparativo entre os caminhos

A migração por partes, na prática

O caminho intermediário resolve a maioria dos casos e funciona assim:

1. Mapeie o sistema por módulos e identifique qual causa mais dor hoje.
2. Coloque uma camada de roteamento na frente, que decide se cada requisição vai para o sistema antigo ou para o novo.
3. Reescreva um módulo no novo padrão, com os dois convivendo sobre a mesma base de dados ou com sincronização definida.
4. Direcione o tráfego daquele módulo para o novo, monitore, e mantenha a possibilidade de reverter.
5. Repita com o próximo módulo, na ordem de dor ou de risco.

As vantagens práticas: cada etapa entrega valor, cada etapa pode ser revertida, o negócio continua evoluindo e o orçamento é aprovado em parcelas justificáveis. A desvantagem é conviver com dois padrões durante um período, administrável, desde que exista um plano com fim datado.

Como decidir com números

Antes de escolher, levante quatro medidas:

1. Horas por mês gastas só mantendo o sistema funcionando (correção, contorno, suporte).
2. Tempo médio para implementar uma mudança pequena hoje.
3. Quantidade de coisas que o negócio precisa e que o sistema não permite, listadas nominalmente, não em geral.
4. Estimativa de horas para reescrever e para refatorar por partes, feita por alguém que leu o código.

Se o item 3 estiver vazio ou contiver apenas inconveniências, refatore. Se contiver impedimentos estruturais e o item 4 mostrar que a refatoração custa mais de 60% a 70% da reescrita, aí a reescrita começa a se justificar.

Se decidir reescrever, faça estas cinco coisas

1. Documente as regras de negócio do sistema atual antes de escrever a primeira linha. Entreviste quem usa, leia o código nos pontos de decisão, teste casos-limite no sistema antigo.
2. Congele o escopo do sistema novo no que o antigo já faz, mais o impedimento que motivou a reescrita. Reescrita com funcionalidades novas embutidas é a receita clássica de projeto que não termina.
3. Mantenha o antigo no ar e planeje um período de convivência com comparação de resultados.
4. Migre dados cedo, não na última semana. Migração descoberta no fim é o motivo mais comum de adiamento de virada.
5. Vire por partes ou por grupos de usuários, nunca todo mundo de uma vez.

A pergunta que resume tudo: o que exatamente o sistema atual impede de fazer? Se você consegue listar isso em itens concretos, a decisão praticamente se escreve sozinha. Se a resposta é um desconforto geral, o problema provavelmente é resolvível com refatoração e uma boa dose de documentação.