Это понятно. Я рассматриваю целесообразность этой миграции, и наличие возможных вариантов новой реализации

Всем привет, у меня создаются таблицы в базе с помощью hibernate. Какие есть варианты чтобы, добавить описание для созданных таблиц?

Есть довольно крупные модули. На груви будет довольно сложно

В первую очередь нужно понять зачем это нужно. Сервисы не справляются с нагрузкой? Пхпшники внезапно закончились?(сомневаюсь)

написать документацию

Корпоративные ограничения. В компании не легализован php, для установки в бой нужна джава

а зачем тогда изначально на пых делали?

У меня ощущение, что ищется не решение, а отговорки.

Это будет долго, больно и дорого, какую бы архитектуру вы не применяли.

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

И поймите меня правильно, переписывать приложение полностью с PHP на Java - это та ещё развлекуха, особенно если ваши разработчики Java не умеют.

Сколько времени делалось PHP приложение? Сколько разработчиков знают, что творится в коде и какая бизнес-логика с какими исключениями реализовывалась? Документация актуальна? Приложение уже в проде?

Если у вас та же команда, которая знает весь код, и все нестандартные решения, и все куски кода типа if skud == 42 //Так сказал Иван Иваныч, но он уже не помнит, почему мы завязываемся именно на 42, да ещё при этом у вас актуальная документация - то вы в хороших условиях. В противном случае - вы попали. Особенно, если приложение в проде.

Наверное, в вашем случае, есть смысл начинать потихоньку заменять куски PHP кода на Java. Сначала развязываете PHP подули через REST или ещё что-нибудь, а потом заменяете на Java отрезанный кусок.

Про 42, вообще такой код просто не пройдет ревью. Даже на самом жутком проекте

Да? Ну, ОК. Не пройдет - и не пройдет.

Вообще - я утрировал. Там может быть просто if, обрабатывающий какой-то особый случай в бизнес-логике

Если полноценное ревью на проекте уже было в то время, когда этот код писался

Это да, но в тырпрайзе обычно такое все же документируется. Даже в самом жутком Легаси которое я видел все расписано в дизайнах джиры. Ну и кодстайл подразумевает какую то адекватную оболочку для этой бизнес логики: наименование переменных/методов/etc

Я вам завидую. Вам везло с проектами. Без шуток и сарказма.

@sigmax А переезд на другую платформу - это реально большая работа и быстренько в чатике за вас этот анализ никто не сделает. Выбираете метрики, по котороым будет оценивать целесообразность, примеряете разные варианты архитектуры, смотрите, что получается, выбираете лучшее. Может оказаться, что дешевле будет купить готовое или вообще отказаться от переписывания и свернуть продукт.

стоимость переезда = стоимость разработки старого решения + стоимость изучения старого решения)

+стоимость найма новой команды (или обучение старой с набиванием шишек) + стоимость простоев из-за переезда (или разработки бесперебойной методики переезда) + стоимость построения инфраструктуры для разработки на новой платформе + стоимость обновления серверов для развертывания + стоимость разработки новых фич (все равно переезжаем, давайте сделаем лучше)

Мне кажется, я забыл ещё пяток слагаемых...

При этом старое решение дальше развивается и надо как то оперативно это переносить в новое

Всем спасибо за ответы. Действительно, идея с большей вероятностью нецелесообразная.