Penso no artigo de Joel Spolsky sobre nunca reescrever código do zero. Para resumir seu argumento: O código não fica enferrujado e, embora possa não parecer bonito depois de muitas versões de manutenção, se funcionar, funciona. O usuário final não se importa com a beleza do código.

Você pode ler o artigo aqui:Coisas que você nunca deve fazer

Eu recentemente assumi um projeto e depois de analisar o código deles, é bem ruim. Eu pensei imediatamente em protótipos que eu havia construído antes e expliquei explicitamente que ele não deveria ser usado em nenhum ambiente de produção. Mas claro, as pessoas não escutam.

O código é construído como um site, não tem separação de interesses, nenhum teste de unidade e duplicação de código em todos os lugares. Nenhuma camada de dados, nenhuma lógica de negócios real, a menos que você conte um monte de classes no App_Code.

Fiz a recomendação às partes interessadas de que, embora devêssemos manter o código existente, fazer lançamentos de correções de bugs e algumas versões menores de recursos, devemos começar a reescrevê-lo imediatamente com o Test Driven Development em mente e com uma separação clara das preocupações . Estou pensando em seguir a rota da ASP.NET MVC.

Minha única preocupação é, claro, o tempo que levaria para reescrever do zero. Não é totalmente complicado, bonito executar o aplicativo da web moinho com a adesão, etc.

Algum de vocês se deparou com um problema semelhante? Qualquer passo em particular que você deu?

ATUALIZAR:

Então ... O que acabei decidindo fazer? Tomei a abordagem de Matt e decidi refatorar muitas áreas.

Como o App_Code estava ficando muito grande e diminuindo o tempo de compilação, removi muitas das classes e as converti em uma biblioteca de classes.

Eu criei uma camada de acesso a dados muito simples, que continha todas as chamadas do ADO e criei um objeto SqlHelper para executar essas chamadas.

Eu implementei um registro mais limpo
solução, que é muito mais concisa.

Embora eu não trabalhe mais neste projeto (financiamento, política, blá blá), eu acho que isso me deu uma visão enorme de quão ruins alguns projetos podem ser escritos, e passos que um desenvolvedor pode tomar para tornar as coisas muito mais limpas, legíveis e justas plana melhor com passos pequenos e incrementais ao longo do tempo.