переписать или не переписать

Question

так что мне нужно поддерживать этот старый унаследованный проект, где одна его часть великолепно написана с помощью Wordpess, множество дрянных пользовательских плагинов, множество скриптов с утками, которые решают ту или иную проблему, база данных тоже разработана очень чисто,есть также другая часть, написанная с Zend, которая тесно связана с WP-частью, также есть другой проект «шедевра», связанный с данными первого проекта.Основная таблица содержит около 1,5 млн записей и должна быть нормализована.теперь этот большой комок гвоздей "работает", также у него есть много LOC, которые являются результатом плохой основы, поэтому поддерживать его очень сложно.Дело в том, как я это вижу, не переписывая, мы теряем в долгосрочной перспективе, потому что мы теряем гибкость как с точки зрения технологии, так и с точки зрения бизнеса, плюс она начинает не масштабироваться, но переписывание - это риск, плюс нам нужнопреобразовать старые данные в новые структуры данных.Хакерская часть меня хочет сломать это, рискнуть и сделать это правильно, но в то же время у меня возникает ощущение, что моя незрелость пытается одновременно откусить слишком большой кусок.Так что ты думаешь?

Answer 1

В таких ситуациях, как ваша, 9 из 10 раз люди предлагают переписать, и они ошибаются.

Если вы не обладаете большими знаниями на уровне приложений о том, что делает система, вы не сможете переписать ее успешно, быстро.

Если система работает сегодня, но во многих отношениях она дрянная, и у вас есть заинтересованность руководства (они владеют программным обеспечением) для «исправления ошибок», то я полагаю, что поэтапный подход часто будет лучше, чем полный при перезаписи.

Я подозреваю, что база данных доставляет вам больше всего головной боли, так что это может быть лучшим местом для начала. Начните с понимания проблемы, которую она решает в настоящее время, и запишите ее. Если между программным обеспечением и базой данных нет слоя (кроме jdbc и т. П.), Добавьте слой. Когда есть слой, отделяющий БД от приложения, вам будет проще изменить БД (и слой), минимизируя влияние на приложение.

В какой-то момент вы будете счастливы с первым, что вы изменили. На этом этапе исправим какую-то другую часть. Повторяйте, пока система не станет «лучше».

Относительно риска: рисковать - это не плохо, но быть небрежным - ужасно. Понимать риски и планировать их снижение.

Answer 2

Хорошая стратегия в таких ситуациях - «задушить» ваше приложение, как это описал Мартин Фаулер:

http://martinfowler.com/bliki/StranglerApplication.html

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

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

Answer 3

В таких ситуациях, как ваша, 9 из 10 раз предлагаю переписать.Рационально, ситуация а) не улучшится, и б) непременно ухудшится.Вы должны укусить пулю, пока не стало слишком поздно.

И слишком поздно, я имею в виду, что что-то ломается полностью, и вам нужно будет не только переписать все это, но и ваша служба также будет отключена (возможно, вы тожепотеря пользователей / клиентов).