Как плавно, поэтапно перенести веб-приложение на другую технологию

Question

У меня есть приложение Coldfusion, разработанное без какой-либо инфраструктуры и почти без архитектуры. Я хотел бы медленно перенести какую-то часть приложения в какую-то инфраструктуру веб-приложений на основе Java.

Исходное приложение должно оставаться основным приложением до конца миграции. В приложении есть пользователь и сеансы, а также множество функций, которые нелегко отделить.

Я ищу разные идеи.

Например, я мог бы попытаться разработать бэкэнд API REST и начать использовать его из приложения ColdFusion, пока у меня не будет Coldfusion только в качестве внешнего интерфейса. Этот процесс должен идти рука об руку с рефакторингом базы данных и миграциями, т.е. новый API должен использовать свою собственную базу данных, поэтому я предполагаю, что разделение базы данных будет необходимо (и, вероятно, возникнут проблемы с синхронизацией базы данных)

Но я бы хотел также перейти на другую технологию интерфейса. Ситуация будет выглядеть следующим образом: пользователи входят в Coldfusion, входят в основную панель мониторинга в Coldfusion, и следующие «некоторые» функции будут обрабатываться другой средой. Это означает, что механизм шаблонов способен понимать пользователя, его роли, его разрешения, воспроизводить тот же графический макет, но он должен обслуживать контент с помощью другой технологии.

Окончательный результат должен заключаться в том, что все функциональные возможности переведены на новую технологию.

Я упоминаю Java, поскольку он каким-то образом связан с ColdFusion, но в принципе можно использовать любую среду веб-приложений. Я также думаю, что Coldfusion, используемый в оригинальном приложении, не актуален. Тот факт, что не используется фреймворк, вероятно, дает мне больше гибкости.

Любое архитектурное предложение приветствуется.

Answer 1

Я недавно сделал именно это. Приложение со спагетти-кодом, разработанное графическим дизайнером с книгой CFML, базой данных MSSQL, которая настолько денормализована, что даже Бизарро не смог ее победить и победить.

Что мы сделали, так это то, что мы оставили старое приложение на месте, построили новое и тщательно его протестировали, усовершенствовали, убедились, что оно способно развиваться (и имеет). Затем мы переключили DNS-коммутатор и разослали объявление о том, что новая система - единственная возможность в будущем.

Затем я создал архивную функцию, которая обеспечивала доступ только для чтения к оставленной нами сумме. Когда-нибудь, если владельцы приложений захотят перенести эти данные, мы можем попробовать это (это не пойдет хорошо), но в целом огромные улучшения убедили всех, что старые вещи нужны только в этом режиме только для чтения.

Очевидно, что это означает, что отчеты возвращаются только к первому дню нового инструмента, но это было либо (с 4-недельным временем разработки), либо они получают все это, и это занимает 8 месяцев, как вы описали.

Это очень хорошо сработало для нас, и, вероятно, это была лучшая работа, которую я сделал здесь.