Когда переписывать кодовую базу с нуля

Я вспоминаю статью Джоэла Спольски о том, что никогда нельзя переписывать код с нуля. Подводя итог его аргументу: код не ржавеет, и, хотя он может не выглядеть красиво после многих выпусков обслуживания, если он работает, он работает. Конечного пользователя не волнует, насколько хорош код.

Вы можете прочитать статью здесь:Вещи, которые вы никогда не должны делать

Я недавно завладел проектом, и после просмотра их кода это довольно ужасно. Я сразу подумал о прототипах, которые я создал ранее, и прямо заявил, что его не следует использовать ни для какой производственной среды. Но, конечно, люди не слушают.

Код построен как веб-сайт, не имеет разделения задач, нет модульного тестирования и дублирования кода повсюду. Нет слоя данных, нет реальной бизнес-логики, если не считать кучу классов в App_Code.

Я рекомендовал заинтересованным сторонам, что, хотя мы должны сохранить существующий код и выпустить исправления ошибок, а также некоторые незначительные выпуски новых функций, мы должны начать переписывать его немедленно с учетом Test Driven Development и с четким разделением интересов. , Я думаю о том, чтобы пойти по маршруту ASP.NET MVC.

Мое единственное беспокойство, конечно, время, которое может потребоваться, чтобы переписать с нуля. Это не совсем сложно, довольно простое приложение для веб-приложений и т. Д.

Кто-нибудь из вас сталкивался с подобной проблемой? Какие конкретные шаги ты предпринял?

UPDATE:

Итак ... Что я в итоге решил сделать? Я выбрал подход Мэтта и решил провести рефакторинг многих областей.

Since App_Code was getting rather large and thus slowing down the build time, I removed many of the classes and converted them into a Class Library.

I created a very simple Data Access Layer, which contained all of the ADO calls, and created a SqlHelper object to execute these calls.

I implemented a cleaner logging
solution, which is much more concise.

Хотя я больше не работаю над этим проектом [финансирование, политика, бла-бла], я думаю, что он дал мне колоссальное понимание того, насколько плохими могут быть написаны некоторые проекты, и шагов, которые может предпринять один разработчик, чтобы сделать вещи намного чище, читабельнее и просто лучше с небольшими, постепенными шагами с течением времени.

Ответы на вопрос(17)

Ваш ответ на вопрос