Como Decidimos Quando Refatorar e Quando Reescrever
Todo desenvolvedor enfrenta esse momento.
A base de código está lenta. Adicionar funcionalidades leva tempo demais. Novos contratados têm dificuldade para entender o sistema. Alguém acaba sugerindo uma reescrita completa.
A equipe geralmente se divide em dois grupos. Um grupo quer começar do zero. O outro grupo teme o fracasso de reescritas passadas. Ambos os lados têm pontos válidos.
Uma reescrita não é uma solução mágica. Muitas vezes leva mais tempo do que o planejado. Você acaba mantendo dois sistemas ao mesmo tempo. Você pode até repetir os mesmos erros na nova versão.
Uma reescrita faz sentido nestes casos específicos:
• O modelo de dados é fundamentalmente errado para o negócio. • A tecnologia está morta e não recebe atualizações de segurança. • As necessidades do negócio mudaram tanto que o sistema original tornou-se obsoleto. • Ninguém na equipe atual entende como o sistema funciona.
Mesmo assim, não faça uma substituição do tipo "big bang". Use o padrão strangler fig. Construa o novo sistema peça por peça, ao lado do antigo.
Na maioria das vezes, o que você realmente precisa é refatorar.
A refatoração é a escolha certa quando:
• Você ainda consegue adicionar funcionalidades, mesmo que seja de forma lenta. • A equipe entende o código atual. • A bagunça está limitada a módulos específicos. • O negócio não pode parar de entregar novas funcionalidades.
Antes de escolher, pergunte por que o código ficou ruim.
Se o problema for dívida técnica, refatore as piores partes. Se o problema for a falta de revisões de código ou uma cultura ruim, uma reescrita não ajudará. Você apenas construirá uma nova bagunça com os mesmos velhos hábitos.
Faça estas perguntas antes de decidir:
• Podemos consertar as piores partes de forma isolada? • O modelo de dados está quebrado para as necessidades atuais do negócio? • Qual conhecimento perderemos se começarmos do zero? • O negócio tem estabilidade para lidar com uma transição longa?
Começar do zero traz uma sensação boa. Terminar a reescrita é a parte difícil. Na maioria das vezes, um plano de refatoração estruturado é mais seguro e eficaz.
Fonte: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk