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

[belugin]

Цитата:

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

Ну т.е. глобальная проблема развития АХ согласно этой статье состоит в том, что код решили переписать "с нуля".

В каком смысле с нуля?

1) Давайте введем какую-то метрику, которая обозначит процент переписанного и посмотрим сколько по ней изменилось - мне кажется не так много но изменения сквозные.

2) Обратите внимание, что в статье говорится о переписывании ВСЕГО с нуля. Переписывание каких-то кусков там рекомендуется.

[sukhanchik]

Цитата:

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

В каком смысле с нуля?

1) Давайте введем какую-то метрику, которая обозначит процент переписанного и посмотрим сколько по ней изменилось - мне кажется не так много но изменения сквозные.

2) Обратите внимание, что в статье говорится о переписывании ВСЕГО с нуля. Переписывание каких-то кусков там рекомендуется.

А ну если ключевое слово ВСЕГО, то я согласен - переписывалось кусками.
Но из того, чтобы я отнес к "ВСЕГО" - это:
1. Глобальная переделка интерфейса. Также, как Office 2003-2007. При этом в D365O тоже ведь интерфейс поменялся.
2. Нормализация таблиц.
Общий принцип, по которому были переписаны настройки ГК (LedgerDimension), справочники номенклатур (EcoRes*), ГАК (DirParty*; это конечно появилось еще в 2009-й версии).
Тут некорректно говорить, что изменение случилось именно в одной версии. Скорее это плавное изменение концепта. Но ... глобального концепта. Может это и не совсем подходит под статью - там все-таки упор был в рамках одной версии. Это изменение концепта ударило по схемам внедрения в рамках импорта данных. Тут конечно формально дело не в MS, но с т.з. покупателя - он особо-то не разделяет покупку лицензий от внедрения системы - т.е. ему нужен результат.

В D365O - из глобального "ВСЕГО" - это опять смена интерфейса и уход в Azure. Да, это не совсем разработка, но это опять глобальное изменение в системе, в результате которого опять заново нужно менять схему внедрения системы. И схему разработки.Т.е. с т.з. "доведения системы до эксплуатации" - процесс глобально меняется.
Мне кажется, что это подходит под ВСЕГО, нет? У автора статьи были конечно немного иные мысли в статье, но суть их как мне кажется в том, что как только мы чего-то (неважно чего - код, платформу, интерфейс, идеологию и т.д.) меняем глобально - то это как раз-таки та ситуация, в которой мы тормозимся на рынке перед конкурентами. Потому что пока все участники рынка (и в первую очередь специалисты по системе) адаптируются к новым изменениям - будет упущено время.

Я неправ?

[belugin]

Цитата:

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

1. Глобальная переделка интерфейса. Также, как Office 2003-2007. При этом в D365O тоже ведь интерфейс поменялся.

2. Нормализация таблиц.
....
Мне кажется, что это подходит под ВСЕГО, нет?

Мне кажется вы смотрите только на то, что изменилось. Попробуйте также сравнить то, что осталось на месте.

Что больше diff(Ax2012, Ax3) или diff(Sap R/3, Ax3)

[sukhanchik]

Цитата:

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

Мне кажется вы смотрите только на то, что изменилось. Попробуйте также сравнить то, что осталось на месте.

Что больше diff(Ax2012, Ax3) или diff(Sap R/3, Ax3)

Дак... я ж естественно смотрю на то, что изменилось. Статья-то об изменениях.
Я согласен, что есть то, что не поменялось. Есть нужные изменения, например, модуль бюджетирования или то, как переписали финансовый блок (я пока не говорю об его архитектуре, а говорю пока про внешность). Т.е. конечно что-то стало и неудобным (ввод данных пользователем по счетам в ЖГК без автоподстановок аналитик к примеру), что-то стало удобным (гибкость аналитик в зависимости от счета и связка их со справочниками к примеру, а модуль бюджетирования научился наконец-таки контролировать).
Есть то, что мало поменялось (склад) и даже можно теперь увеличить количество складских аналитик - все это здорово. И то, что поменялось и то, что осталось тем же. ОСы российские к примеру, не поменялись и это тоже здорово. (я пока говорю про АХ 2012 и АХ 3)

Но есть некоторые вещи, которые поменялись глобально. Навскидку пока приходят 2 вещи - это интерфейс и структура данных. Хорошо это или плохо - это покажет время. То самое время, за которое все адаптируются к новым реалиям. Все - это специалисты - внедренцы, это новые специалисты, которые не видели предыдущих версий, это пользователи старых и новых версий и ЛПР (лица, принимающие решения).
Вот про это я и говорю.

А какой смысл сравнивать разницу между AX2012 и AX3 с разницей между SAP R/3 и AX 3? SAP R/3 не объявляет себя преемницей AX3 с одной стороны, а с другой стороны - MS не позиционирует AX 2012 / D365O, как отдельный продукт, который продается параллельно с АХ3. Более того, по сути - MS на правах владельца - не выпускает больше AX3.

Здесь более корректно сравнивать развитие AX 3 до AX 2012 / D365O и SAP R/3.
У SAP есть один очень важный момент - основной код ядра уже не менялся лет так ... дцать. Со всеми своими багами и фичами. И все специалисты по SAP знают эти особенности и научились их обходить. И в этом сила SAP, что есть понятный сценарий внедрения SAP, который можно оценить и реализовать. Да, кому-то по карману, а кому-то и не по карману, но все это прогнозируемо.
А с АХ получилось так, что со времен я думаю даже 2.5 и до 2009 был некий плюс-минус единый механизм внедрения и использования системы. Был плюс-минус единый интерфейс форм и можно было найти заветную кнопку чуть ли не вслепую.
Было понимание, что каждая форма смотрит на одну-две таблицы (множество датасорсов не приветствовалось) и можно легко выгрузить данные (Ctrl+C, Ctrl+V). А связи между таблицами тоже были плюс-минус осмысленные (ГК234323 все же легче запоминается человеком, нежели 234765323 (RecId), который еще и вдобавок системой генерится (самому неотредактировать RecId).

Конечно сейчас сделано много инструментов - интеграция с офисом, запоминание кнопок на уровне иконок в ленте, всякие DMF, SSRS и все такое, но ко всем этим инструментам рынок должен будет успеть адаптироваться. Это и сейчас видно - если даже посмотреть на MS, то все продукты выходят с опережением. Например, Office 2016 вышел в начале 2016-го года (или даже раньше); при этом сейчас многие используют Office 2013 или 2016, ну на крайняк - 2010. И уж думаю, что 2007-ю или уж паче 2003-ю версию никто не используют. К 2007-й все привыкали и наконец привыкли.
В случае с АХ - получается, что 2012-ю версию выпустили в 2011 году (в августе) и ... к ней все сейчас адаптируются. Кто-то уже работает, кто внедряется, а кто еще остался на 2009-й. Но ... на дворе 2017-й год и AX 2015 не выходила. Именно АХ, как продолжение. Потому что рынок еще адаптировался.

Поэтому для успешного повторения пути SAP - MS-у нужно остановиться в разработке и начать усиленно продвигать процесс внедрения последней версии. Это обучающие материалы, методические указания, демо-данные и т.д. Естественно все на языке той страны, в которой она будет внедряться.

А иначе - для тех, кто "не успел" перейти с АХ 3 или АХ 4 - D365O будет совершенно новой системой, где изменено "ВСЕГО".

[belugin]

Цитата:

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

Дак... я ж естественно смотрю на то, что изменилось. Статья-то об изменениях.

Статья про переписывание с нуля в стиле того, что предлагает ax_mct. Не всякое изменение есть переписывание. Замена искусственных ключей на суррогатные есть просто преобразование кода. Для этого не надо ставить задачу за ново и писать код с чистого листа. Распил таблицы на несколько - это тоже инкрементное изменение.

1) У меня впечатление, что большая часть кодовой базы осталась на месте, только подвергнута инкрементным преобразованиям в некоторой части

2) Иногда последовательность таких преобразований накопленная за три года выглядит как переписывание.

3) Некоторые куски действительно были переписаны

Цитата:

Но есть некоторые вещи, которые поменялись глобально. Навскидку пока приходят 2 вещи - это интерфейс и структура данных.

Я не вижу кардинальных изменений в интерфейсе в его семантике. В-основном изменилось оформление и какие-то общие правила. Группы почти все остались на месте и после усвоения почти все навыки можно использовать. (С Ax7 в этом смысле знаком меньше - но внутри примерно то же самое, как мне кажется).

То есть изменилось не описание интерфейса бизнесобъекта, а набор правил, по которым преобразуется в UI.

Цитата:

А какой смысл сравнивать разницу между AX2012 и AX3 с разницей между SAP R/3 и AX 3?

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

Если смотреть только на изменения, то согласен - 100% изменено .

Цитата:

Поэтому для успешного повторения пути SAP - MS-у нужно остановиться в разработке и начать усиленно продвигать процесс внедрения последней версии. Это обучающие материалы, методические указания, демо-данные и т.д. Естественно все на языке той страны, в которой она будет внедряться.

Это, мне кажется, офтопик - здесь мы про миграцию на разные платформы и переписывание с нуля. С моей точки зрения, ни Ax6 ни Ax7 не являются системой переписанной с нуля. Какие-то куски - да.

[mazzy]

Цитата:

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

Не всякое изменение есть переписывание.

да

Цитата:

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

Замена искусственных ключей на суррогатные есть просто преобразование кода. Распил таблицы на несколько - это тоже инкрементное изменение.

нет.
структура базы - это публичный интерфейс.

Цитата:

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

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

[mazzy]

Цитата:

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

Я не вижу кардинальных изменений в интерфейсе в его семантике.

исчез MDI, исчез dynalink

Цитата:

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

Статья про переписывание с нуля - соответстенно надо понять, что переписано, что преобразовано, что осталось как было.

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

к задаче переписывания нужно подходить со стороны пользователя и внешнего разработчика (который пользуется документированными API).

если пользователю придется изменять свои навыки - система изменена (и не важно как оно внутри устроено)
если разработчику придется менять свои наработки под другое API - система изменена (и не важно как оно внутри устроено)


типичный пример, 64битное приложение и 32битная версия.
FAR какой-нибудь, Total Commander, FireFox, MS Office.

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

типичный пример легко переписываемого с нуля приложения - ipscan
https://github.com/angryziber/ipscan, http://angryip.org/
выступление автора, где он рассказывает историю приложения и как он дошел до версии 3
https://www.youtube.com/watch?v=y8yKxmz6iDY

===============
возвращаясь к исходному вопросу:

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

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

[sukhanchik]

Цитата:

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

С откровениями Джоэла надо быть аккуратнее, нельзя забывать чем он занимается сам.

Спасибо за поправку. Я это не учел.

Цитата:

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

я бы просто посоветовал различать оправданный и неоправданный рефакторинг.

Да, верно. Я поэтому это и спросил в этой теме, потому что переписывание всей системы - это вопрос грани между оправданным и неоправданным рефакторингом.

Цитата:

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

к задаче переписывания нужно подходить со стороны пользователя и внешнего разработчика (который пользуется документированными API).

если пользователю придется изменять свои навыки - система изменена (и не важно как оно внутри устроено)
если разработчику придется менять свои наработки под другое API - система изменена (и не важно как оно внутри устроено)

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

В АХ 2012 очень показательно свойство Style на элементе управления Tab. Одно изменение и форма из "привычного для AX 2...AX 2009" вида превращается в вид AX 2012 (и наоборот). С т.з. разработки - ерунда, а с т.з. пользователя - вертикальные вкладки мозг взрывают поначалу (особенно если он раньше работал с AX 2009 и более ранними версиями).
В AX2009 было аналогичное свойство на дизайне формы, которое "легким движением руки" возвращало MDI-интерфейс, использовавшийся в АХ 4 и более ранних версиях.

В общем - большое спасибо всем участникам за дискуссию и за формулировки. Отдельное спасибо Максиму Белугину за взгляд изнутри MS.

[macklakov]

Цитата:

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

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

С откровениями Джоэла надо быть аккуратнее, нельзя забывать чем он занимается сам. У него небольшая контора, производящая нишевый софт. Поэтому он на все смотрит со своей колокольни. Да, для мелюзги очень важно постоянно в движении быть, иначе крупные монстры их раздавят. Но у крупных монстров выигрышная тактика может быть совсем другой.
Рассматривая приведенный пример, MS может переписывать свой IE несколько раз с нуля и рано или поздоно у них получится написать что-то востребованное рынком. Для Netscape первая же ошибка стала фатальной.
В нашем случае, идет битва титанов, которые немного неповоротливы, но ресурсами не обделены. SAP все переписывает на Hana, MS перевел все на .net, а теперь в облако. Т.е. переписывание "с нуля" не просто имеет смысл, оно активно используется обеими сторонами.