|
22.03.2017, 20:06 | #1 |
Banned
|
Цитата:
Сообщение от NetBus
Добрый день!
...а именно миграции приложения с java на php или python или обратно +)) иных языков, с экспертизой написанного за несколько лет и потраченных на разработку сотен тысяч человеко-часов.С legacy кодом от нескольких поколений разработчиков? Компании масштабом так от нескольких тысяч человек. Дешевле написать с нуля улучшенную версию чем мигрировать. Экспертиза - она не в коде, а в людях. То есть сама идея миграции "код-код"- пагубна, но написать улучшенную версию используя "экспертиза-код" - это да. Если конкретно о Java, PHP и Python - то они прекрасно могут ужиться в одном приложении. Хотя я бы рекомендовал PHP Цитата:
Сообщение от trud
О.. кстати 2 дня назад мне такой же вопрос задал босс. нужно оценить потенциальное время на перевод решения с AX D365 на другие языки(само решение - порядка 100 форм, большинство функциональности сбоку, что-то типа русских договоров). на выбор были предложены С#, навижн, CRM..(но можно предложить что-то свое)
кто-нибудь имел опыт кодирования в этих системах - насколько там все сложно или просто кодировать по сравнению с АХ? Для desktop версии С# будет дешевле всего. Раза в два "дороже" чем в desktop AX. Для web версии и платформы - посмотрите Zoho CRM как неплохой вариант. |
|
22.03.2017, 20:13 | #2 |
Участник
|
да.
причем люди - не только программисты. поэтому - нет, не дешевле |
|
22.03.2017, 21:12 | #3 |
Banned
|
Любая миграция упирается не в трансляцию кода в код, а в разность фреймворка и его библиотек. И миграцией можно назвать лишь в силу наличия экспертизы в предметной области, но с точки зрения программирования это написание нового приложения.
Понятно что миграцию .NET языков скажем из VB.NET to C sharp я даже не рассматриваю если скажем это все тот же ASP.NET Forms framework. Это даже не миграция, а лишь перевод синтаксиса. Понятно что если есть какой-то слой front-end в JS или back-end в Java, можно переписывать не все, а только один слой. Но если говорить о нашей типичной ERP мешанине, то мне кажется что ее надо или не трогать вообще или написать заново. Мигрировать завал сучьев - гм |
|
22.03.2017, 21:53 | #4 |
Участник
|
Цитата:
Цитата:
Или опять уводите в оффтопик. Не надо этого делать. Вопрос был не про любую миграцию. а про миграцию корпоративных приложении с одного языка на другой. |
|
22.03.2017, 22:47 | #5 |
Banned
|
Цитата:
Вот это вот - миграция приложения: "Миграция корпоративного веб-приложения в службу приложений 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, переписывать придется все. Какая тут бездумная и/или автоматизированная миграция кода? Полноценная иммиграция. |
|
22.03.2017, 23:21 | #6 |
Участник
|
Цитата:
|
|
23.03.2017, 09:06 | #7 |
Участник
|
Цитата:
Модуль который тонкими перемычками соединяется с окружением а внутри перемешан или набор мелких модификаций, или и то и то. И насколько ценно переносить изолированную часть и насколько надо чтобы работа над конвертированной частью продолжалась (доработки и фиксы). Можно например скопилировать ваш модуль в IL и посмотреть чем-то типа Telerik Decompiler и взять за основу получившийся код. |
|
23.03.2017, 10:37 | #8 |
Участник
|
Цитата:
И если сущности еще можно как-то перетащить, например заказ это набор полей в шапке и набор полей в строках. С алгоритмами сложнее, если в одном языке есть сборщик мусора, а в другом нет и это будет проблема. С языком еще сложнее. Как пример - переводить X++ на язык в котором нет контейнеров? Возникают те же проблемы, что и с переводом с человеческого на человеческий, red brick это красный кирпич, но red fox это рыжая лиса, а не красная. И если это не учитываешь, получается не english, а рунглиш. Проще и дешевле переписать. Последний раз редактировалось AlexeyS; 23.03.2017 в 10:40. |
|
23.03.2017, 10:49 | #9 |
Участник
|
хм... давайте я попробую в последний раз.
корпоративное приложение = любое приложение + корпоративные пользователи. корпоративные пользователи != обычные пользователи. корпоративные пользователи ~ много-много-много обычных пользователей. поэтому миграция массовых приложений (вконтакте, фейсбук, инстаграм, paypal и т.п.) похожа на миграцию корпоративных приложений. но миграция корпоративных приложений отличается от миграции "любого приложения" именно наличием работающих пользователей. и не сводится к миграции "любого приложения". |
|
23.03.2017, 13:08 | #10 |
Banned
|
Цитата:
Сообщение от mazzy
хм... давайте я попробую в последний раз.
корпоративное приложение = любое приложение + корпоративные пользователи. корпоративные пользователи != обычные пользователи. корпоративные пользователи ~ много-много-много обычных пользователей. поэтому миграция массовых приложений (вконтакте, фейсбук, инстаграм, paypal и т.п.) похожа на миграцию корпоративных приложений. но миграция корпоративных приложений отличается от миграции "любого приложения" именно наличием работающих пользователей. и не сводится к миграции "любого приложения". + много-много пользователей + обеспечение непрерывности Я бы добавил зависимость от пользователей как специфику + они капризны + рядом с тобой То есть в случае онлайн-магазина/продукта требования определяются без политики и множества участников, а в случае корпоративного ПО - прямое удовлетворение ожиданий конкретных пользователей. То есть в случае корпоративного ПО не ты предлагаешь пользователям новый интерфейс, а они диктуют что они хотят. На практике это означает что они хотят принципиально тот же UI чтобы им было как привычно. Думаю что вот это вот связывание по рукам и ногам привычками пользователей - и есть особенность корпоративного ПО. А много и непрерывность - это не только там. P.S. MS как небожитель - исключение, я беру ситуацию не вендора который далек от пользователей, а интегратора/IT на земле. P.P.S. То есть миграция корпоративного ПО отличается необходимостью сохранения пользовательского опыта. В большей степени чем любой другой софт, так как корпоративное ПО - это рабочее место так как это есть для водителя автомобиля. И скорее всего "миграция" интерфейса важнее чем миграция кода. Зы: MS "чтобы все выглядело как MS Office" для "того же пользовательского опыта" - не рассматриваю. Это опять неудачное исключение. Не дизайн, а расположение - вот что есть пользовательский опыт. Рычаг ручного тормоза в бардачке но выполненный в привычной форме того что мы привыкли держать в правой руке - это не тот же пользовательский опыт. Последний раз редактировалось ax_mct; 23.03.2017 в 13:29. Причина: P.P.S. |
|
23.03.2017, 14:52 | #11 |
Участник
|
Цитата:
Сообщение от mazzy
хм... давайте я попробую в последний раз.
корпоративное приложение = любое приложение + корпоративные пользователи. корпоративные пользователи != обычные пользователи. корпоративные пользователи ~ много-много-много обычных пользователей. поэтому миграция массовых приложений (вконтакте, фейсбук, инстаграм, paypal и т.п.) похожа на миграцию корпоративных приложений. но миграция корпоративных приложений отличается от миграции "любого приложения" именно наличием работающих пользователей. и не сводится к миграции "любого приложения". корпоративные пользователи в отличие от обычных пользователей имеют влияние, хоть и опосредованное, на производителя ПО. граничные случаи хороши наглядностью вот представь такой вариант, люди работают на 3 аксапте 10 лет, а утром приходят и видят, что вместо иконки на рабочем столе у них ярлычок от браузера. они запускают его и РАБОТАЮТ КАК РАНЬШЕ, может быть только чуть-чуть отличаются шрифты и цветовая схема. Язык поменялся? да. И теперь их клиент в браузере на HTML5, а в бэкэнде вообще непонятно что, то-ли PHP, то-ли NET и вообще NoSQL в облаках. |
|
|
|