Переписывание приложения на другом языке

[trud]

О.. кстати 2 дня назад мне такой же вопрос задал босс. нужно оценить потенциальное время на перевод решения с AX D365 на другие языки(само решение - порядка 100 форм, большинство функциональности сбоку, что-то типа русских договоров). на выбор были предложены С#, навижн, CRM..(но можно предложить что-то свое)
кто-нибудь имел опыт кодирования в этих системах - насколько там все сложно или просто кодировать по сравнению с АХ?

[ax_mct]

Цитата:

Сообщение от NetBus

Добрый день!
...а именно миграции приложения с java на php или python или обратно +)) иных языков, с экспертизой написанного за несколько лет и потраченных на разработку сотен тысяч человеко-часов.С legacy кодом от нескольких поколений разработчиков? Компании масштабом так от нескольких тысяч человек.

Микросервисы/REST API между слоями/компонентами приложения написанного на разных языках.

Дешевле написать с нуля улучшенную версию чем мигрировать. Экспертиза - она не в коде, а в людях. То есть сама идея миграции "код-код"- пагубна, но написать улучшенную версию используя "экспертиза-код" - это да.

Если конкретно о Java, PHP и Python - то они прекрасно могут ужиться в одном приложении. Хотя я бы рекомендовал PHP

Цитата:

Сообщение от trud

О.. кстати 2 дня назад мне такой же вопрос задал босс. нужно оценить потенциальное время на перевод решения с AX D365 на другие языки(само решение - порядка 100 форм, большинство функциональности сбоку, что-то типа русских договоров). на выбор были предложены С#, навижн, CRM..(но можно предложить что-то свое)
кто-нибудь имел опыт кодирования в этих системах - насколько там все сложно или просто кодировать по сравнению с АХ?

Если это не вертикальное решение для продажи, а для себя, то использовать MS навижн или MS CRM как платформу для вашего сбоку - это странно.

Для desktop версии С# будет дешевле всего. Раза в два "дороже" чем в desktop AX.

Для web версии и платформы - посмотрите Zoho CRM как неплохой вариант.

[mazzy]

Цитата:

Сообщение от ax_mct

Экспертиза - она не в коде, а в людях.

да.
причем люди - не только программисты.

Цитата:

Сообщение от ax_mct

Дешевле написать с нуля улучшенную версию чем мигрировать.

поэтому - нет, не дешевле

[ax_mct]

Цитата:

Сообщение от mazzy

да.
причем люди - не только программисты.

поэтому - нет, не дешевле

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

Понятно что миграцию .NET языков скажем из VB.NET to C sharp я даже не рассматриваю если скажем это все тот же ASP.NET Forms framework. Это даже не миграция, а лишь перевод синтаксиса.

Понятно что если есть какой-то слой front-end в JS или back-end в Java, можно переписывать не все, а только один слой. Но если говорить о нашей типичной ERP мешанине, то мне кажется что ее надо или не трогать вообще или написать заново.
Мигрировать завал сучьев - гм

[mazzy]

Цитата:

Сообщение от NetBus

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

Цитата:

Сообщение от ax_mct

Любая миграция упирается не в трансляцию кода в код, а в разность фреймворка и его библиотек.

Вы опять вне контекста.
Или опять уводите в оффтопик. Не надо этого делать.


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

[ax_mct]

Цитата:

Сообщение от mazzy

Вы опять вне контекста.
Или опять уводите в оффтопик. Не надо этого делать.

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

Виноват. Но корпоративным любое приложение делает только его предназначение. C точки зрения технологий и языков это может быть что угодно.

Вот это вот - миграция приложения:
"Миграция корпоративного веб-приложения в службу приложений Azure"
https://docs.microsoft.com/ru-ru/azu...rom-iis-server

А вот это вот миграция кода/проекта которой все равно корпоративное это приложение или домохозяек
Translate existing C# code into native PHP code
http://www.cs2php.com/
http://www.cs2php.com/how-to-begin.htm

В принципе типичное и живое корпоративное приложение отличается. Мешаниной кода и нарушением правил проектирования. Что делает любую миграцию кода полной дурью. Проще взять новую платформу и внедрить решение заново.

Да даже если бы тот проект в AX/D365 был идеален с точки зрения проектирования и разделения логики - все равно UI писать заново в новой системе, а c учетом того что все прыгает от UI и обслуживает UI, переписывать придется все. Какая тут бездумная и/или автоматизированная миграция кода? Полноценная иммиграция.

[mazzy]

Цитата:

Сообщение от ax_mct

Виноват. Но корпоративным любое приложение делает только его предназначение.

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

Цитата:

Сообщение от mazzy

да.
причем люди - не только программисты.
поэтому - нет, не дешевле

[belugin]

Цитата:

Сообщение от ax_mct

В принципе типичное и живое корпоративное приложение отличается. Мешаниной кода и нарушением правил проектирования. Что делает любую миграцию кода полной дурью. Проще взять новую платформу и внедрить решение заново.

Вопрос, насколько эта мешанина внутри себя или это мешанина сама по себе.

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

Можно например скопилировать ваш модуль в IL и посмотреть чем-то типа Telerik Decompiler и взять за основу получившийся код.

[AlexeyS]

Цитата:

Сообщение от mazzy

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

Любое приложение это набор сущностей, плюс связи между ними плюс язык. В корпоративных приложениях сущностей много, а связей очень много.
И если сущности еще можно как-то перетащить, например заказ это набор полей в шапке и набор полей в строках. С алгоритмами сложнее, если в одном языке есть сборщик мусора, а в другом нет и это будет проблема. С языком еще сложнее. Как пример - переводить X++ на язык в котором нет контейнеров?
Возникают те же проблемы, что и с переводом с человеческого на человеческий, red brick это красный кирпич, но red fox это рыжая лиса, а не красная. И если это не учитываешь, получается не english, а рунглиш. Проще и дешевле переписать.

[mazzy]

Цитата:

Сообщение от AlexeyS

Любое приложение это набор сущностей, плюс связи между ними плюс язык.

хм... давайте я попробую в последний раз.

корпоративное приложение = любое приложение + корпоративные пользователи.
корпоративные пользователи != обычные пользователи.
корпоративные пользователи ~ много-много-много обычных пользователей.

поэтому миграция массовых приложений (вконтакте, фейсбук, инстаграм, paypal и т.п.) похожа на миграцию корпоративных приложений.

но миграция корпоративных приложений отличается от миграции "любого приложения" именно наличием работающих пользователей. и не сводится к миграции "любого приложения".

Цитата:

Сообщение от mazzy

причем люди - не только программисты.
поэтому - нет, не дешевле

[macklakov]

Цитата:

Сообщение от trud

на выбор были предложены С#, навижн, CRM

По моему личному опыту, в CRM что-то делать в несколько раз дольше, чем в AX. При этом, если AX все равно использовать надо, лицензий в 2 раза больше.

[griefon]

Цитата:

Сообщение от macklakov

По моему личному опыту, в CRM что-то делать в несколько раз дольше, чем в AX

Очень зависит от конкретной задачи. Некоторые вещи делаются заметно быстрее. В несколько раз дольше, это когда из CRM начинают делать учетную систему.

[griefon]

Цитата:

Сообщение от trud

О.. кстати 2 дня назад мне такой же вопрос задал босс. нужно оценить потенциальное время на перевод решения с AX D365 на другие языки(само решение - порядка 100 форм, большинство функциональности сбоку, что-то типа русских договоров). на выбор были предложены С#, навижн, CRM..(но можно предложить что-то свое)
кто-нибудь имел опыт кодирования в этих системах - насколько там все сложно или просто кодировать по сравнению с АХ?

Могу про CRM сказать - сильно зависит от количества логики и расчетов. Чем больше расчетов, тем сложнее. Если просто формы, таблицы, связи и отчеты - то легко.