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

[AlexeyS]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

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

Цитата:

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

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

[ax_mct]

Цитата:

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

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

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

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

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

Ага, то есть
+ много-много пользователей
+ обеспечение непрерывности
Я бы добавил зависимость от пользователей как специфику
+ они капризны
+ рядом с тобой

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

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

Думаю что вот это вот связывание по рукам и ногам привычками пользователей - и есть особенность корпоративного ПО. А много и непрерывность - это не только там.

P.S. MS как небожитель - исключение, я беру ситуацию не вендора который далек от пользователей, а интегратора/IT на земле.

P.P.S. То есть миграция корпоративного ПО отличается необходимостью сохранения пользовательского опыта. В большей степени чем любой другой софт, так как корпоративное ПО - это рабочее место так как это есть для водителя автомобиля. И скорее всего "миграция" интерфейса важнее чем миграция кода.

Зы: MS "чтобы все выглядело как MS Office" для "того же пользовательского опыта" - не рассматриваю. Это опять неудачное исключение. Не дизайн, а расположение - вот что есть пользовательский опыт. Рычаг ручного тормоза в бардачке но выполненный в привычной форме того что мы привыкли держать в правой руке - это не тот же пользовательский опыт.

[AlexeyS]

Цитата:

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

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

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

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

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

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

граничные случаи хороши наглядностью
вот представь такой вариант, люди работают на 3 аксапте 10 лет, а утром приходят и видят, что вместо иконки на рабочем столе у них ярлычок от браузера. они запускают его и РАБОТАЮТ КАК РАНЬШЕ, может быть только чуть-чуть отличаются шрифты и цветовая схема.
Язык поменялся? да. И теперь их клиент в браузере на HTML5, а в бэкэнде вообще непонятно что, то-ли PHP, то-ли NET и вообще NoSQL в облаках.

[mazzy]

давайте.

Цитата:

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

граничные случаи хороши наглядностью
вот представь такой вариант, люди работают на 3 аксапте 10 лет, а утром приходят и видят, что вместо иконки на рабочем столе у них ярлычок от браузера. они запускают его и РАБОТАЮТ КАК РАНЬШЕ, может быть только чуть-чуть отличаются шрифты и цветовая схема.
Язык поменялся? да. И теперь их клиент в браузере на HTML5, а в бэкэнде вообще непонятно что, то-ли PHP, то-ли NET и вообще NoSQL в облаках.

прекрасный граничный случай.
только и вы тоже где-то вне контекста. или уводите разговор в сторону.

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


было.

Цитата:

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

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

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

и мы все еще говорим:

Цитата:

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

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

[ax_mct]

Цитата:

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

Цитата:

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

я ответил: поэтому - нет, не дешевле
и мы все еще говорим:
"про миграцию корпоративных приложении с одного языка на другой"

Те примеры которые у меня в голове это либо достаточно легкие приложения которые легче с чистого листа либо в принципе неподьемные которые невозможно переписать.

Например занесение рабочего времени/командировочных расходов через web-interface на базе AX EP и Sharepoint. Тормозит, не нравится интерфейс, требуются кастомизации в силу специфики. Берется open-source PHP как например time tracking http://www.kimai.org/ или похожее и кастомизируется.
О какой миграции тут может быть речь?

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

А писать "с нуля" - это я про кастомизации в новой системе с нуля. Мы же не ожидаем что кто-то после/из AX/D365 захочет написать свое ERP c нуля?
Нет, этот кто-то возьмет как платформу что-то типа https://github.com/odoo/odoo
и будет писать кастомизации с нуля. Потому как переносить старый код и старую логику прутик за прутиком - не эффективно.