Recuerdo el artículo de Joel Spolsky sobre nunca reescribir el código desde cero. Para resumir su argumento: el código no se oxida, y si bien puede que no se vea bien después de muchas versiones de mantenimiento, si funciona, funciona. Al usuario final no le importa lo bonito que es el código.

Puedes leer el artículo aquí:Cosas que nunca debes hacer

Recientemente me he hecho cargo de un proyecto y después de revisar su código, es bastante horrible. Inmediatamente pensé en los prototipos que había construido antes, y declaré explícitamente que no debería usarse para ningún entorno de producción. Pero claro, la gente no escucha.

El código se construye como un sitio web, no tiene separación de preocupaciones, no hay pruebas de unidad y duplicación de código en todas partes. Sin capa de datos, sin lógica empresarial real, a menos que cuente un montón de clases en App_Code.

Le recomendé a los interesados ​​que, si bien debemos mantener el código existente y hacer versiones de corrección de errores, y algunas versiones de características menores, debemos comenzar a reescribirlo de inmediato con Test Driven Development en mente y con una clara separación de preocupaciones. . Estoy pensando en ir por la ruta MVC de ASP.NET.

Mi única preocupación es, por supuesto, el tiempo que puede llevar reescribir desde cero. No es del todo complicado, es una aplicación web bastante simple con membresía, etc.

¿Alguno de ustedes ha encontrado un problema similar? ¿Algún paso particular que tomaste?

ACTUALIZAR:

Entonces ... ¿Qué decidí hacer? Tomé el enfoque de Matt y decidí refactorizar muchas áreas.

Como App_Code se estaba haciendo bastante grande y, por lo tanto, ralentizaba el tiempo de compilación, eliminé muchas de las clases y las convertí en una biblioteca de clases.

Creé una capa de acceso a datos muy simple, que contenía todas las llamadas ADO, y creé un objeto SqlHelper para ejecutar estas llamadas.

Implementé un registro más limpio.
Solución, que es mucho más concisa.

Si bien ya no trabajo en este proyecto [financiamiento, política, bla bla], creo que me dio una idea enorme de lo mal que se pueden escribir algunos proyectos, y los pasos que un desarrollador puede tomar para hacer las cosas mucho más limpias, legibles y simples. Se aplana mejor con pequeños pasos incrementales a lo largo del tiempo.