4 года Dynamics AX 2012 - Курилка

MikeR · 14.12.2016, 16:28

Как-то незаметно канула годовщина презентации последней, по всей видимости on premise Dynamics AX 2012. Четыре года как один день! А сколько было надежд....

Нам показывали, что такое хорошо: CIL, там все дела, полная интеграция с студией.. Крутяк думали мы...

DAX.Company · 14.12.2016, 16:47

Я немного успел поиметь гешефт с этой версией. Хотя если бы знал 4 года назад сколько сил на изучение/продажи уйдет, то не стал бы браться с таким выхлопом. А жаль, что не пошла. Версия системы то не плохая.. Теперь вот не понятно на что надеяться. Надеждами сыт не будешь. Заказчики нужны и прибыль.

macklakov · 15.12.2016, 06:24

Цитата:

Сообщение от DAX.Company

Версия системы то не плохая...

Ага, к R3 основные косяки разгребли, стало терпимо. Да и пообвыклись уже.

ax_mct · 14.12.2016, 18:36

Что хороним? Надежды или версию?
Вроде еще живая AX 2012.

DAX.Company · 14.12.2016, 19:09

Цитата:

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

Что хороним? Надежды или версию?

Надежды на версию хороним. Где ж она живая то. Пару десятков проектов по России

cuba · 15.12.2016, 11:34

Цитата:

Сообщение от DAX.Company

Надежды на версию хороним. Где ж она живая то. Пару десятков проектов по России

Господа, как по мне, то ориентироваться при работе с АХ нужно не на рынок СНГ

ice · 14.12.2016, 19:17

а почему продаж нет? неужели все продажники ушли торговать пирожками?

DAX.Company · 14.12.2016, 19:33

Цитата:

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

а почему продаж нет? неужели все продажники ушли торговать пирожками?

Да. Такие уж продажники продажные. Любят продавать то что продается.

ice · 14.12.2016, 19:38

Цитата:

Сообщение от DAX.Company

Да. Такие уж продажники продажные. Любят продавать то что продается.

т.е. не в продукте дело, а в рекламе?

DAX.Company · 14.12.2016, 20:10

Цитата:

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

т.е. не в продукте дело, а в рекламе?

Ну да. В рекламе продукта

**fed** · 15.12.2016, 10:58

Спустя 4 года могу от себя добавить, что среди нововведений DAX2012 только одно мне кажется безнадежным - Subledger/Distributions/Source document architecture. Все остальное либо уже довели, либо оно может быть доведено в обозримом будущем. (Конечно если весь пар в облака не уйдет). А вот эта милая фича - классический пример того как кривая в прикладном смысле постановка приводит к кривому коду. Если у тебя изначально кривые user stories, то никакие паттерны и никакие грамотные разработчики не помогут - противоречия в прикладной области неизбежно приводят к кривизне и заплаткам в коде.

**Vadik** · 15.12.2016, 11:18

Цитата:

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

Спустя 4 года могу от себя добавить, что среди нововведений DAX2012 только одно мне кажется безнадежным - Subledger/Distributions/Source document architecture

А бюджетирование, которое наполовину в X++, наполовину на хранимых процедурах, ты наверное еще не отлаживал ?

**fed** · 15.12.2016, 11:34

Цитата:

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

А бюджетирование, которое наполовину в X++, наполовину на хранимых процедурах, ты наверное еще не отлаживал ?

Мне просто повезло

Но вообще как-то финансисты наши со стандартным бюджетированием справляются. Но 95% проблем в финансовом модуле кончаются тем что мы отправляем в Микрософт очередную ошибку в распределениях.

Morpheus · 28.12.2016, 17:57

Цитата:

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

...что среди нововведений DAX2012 только одно мне кажется безнадежным - Subledger/Distributions/Source document architecture.

У меня сложилось впечатление, что функционльность Subledger/Distributions/Source document перенесли из другого приложения, написанного на хранимых процедурах. В ней нет и намека на ООП. Одни временные таблицы и куча запросов группирует затем перегруппировывает записи читая их из одних таблиц и записывая в другие. Читать такой код сложно, исправлять/расширять еще сложнее.

macklakov · 29.12.2016, 05:09

Цитата:

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

У меня сложилось впечатление, что функционльность Subledger/Distributions/Source document перенесли из другого приложения, написанного на хранимых процедурах. В ней нет и намека на ООП.

Я бы скзал что основная часть нового системного кода в 2012 написана вчерашними web-программистами. Заслуженными ветеранами asp кодинга. Поэтому ощущается большое недоверие структурам данных, к x++ запросам, к временным таблицам. Из-за этого так часто попадаются таблицы которые используются как временные, являсь обычными, а это, в свою очередь, приводит к конфликтам и накоплению мусорных записей. Еще ощущается полное непонимание, зачем нужен сервер приложений. Поэтому механизм кэширования не развивается, застрял на уровне конца 90-х и больше тормозит систему, чем ускоряет работу.
В сущности, morphX и x++ у них явно путаются под ногами, раздражают, и они хотели бы все это переписать под "нормальную" архитектуру. Но избавиться пока не могут, т.к. открытость кода и простота модификации является тем конкурентным приемуществом, благодаря которому система все еще представлена на рынке, несмотря на всю недоделанность. Для сравнения, разработка через add-on's в "правильном" CRM на порядки сложнее и "общедоступные" C# программисты в CRM, на поверку, оказываются очень редки и дороги.

**fed** · 29.12.2016, 09:55

Цитата:

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

У меня сложилось впечатление, что функционльность Subledger/Distributions/Source document перенесли из другого приложения, написанного на хранимых процедурах. В ней нет и намека на ООП. Одни временные таблицы и куча запросов группирует затем перегруппировывает записи читая их из одних таблиц и записывая в другие. Читать такой код сложно, исправлять/расширять еще сложнее.

Согласно утечке от одного из локализаторов (теперь уже бывшего), спецификация на эту фичу была написана каким-то нанятым с улицы программ-манагером, без знания аксапты и вообще серьезного опыта в финансовых системах. Этот чувак на полпути к выпуску Ax2012 свалил постановщиком в скайп, и к моменту релиза, модулем занимался уже третий программ-манагер. По пути они поимели очень много проблем с производительностью и вынуждены были код несколько раз очень всерьез переделывать. Правда у меня ощущение от стиля кодинга - диаметрально протовоположные. Там на каждый чих иерархия классов и две-три интерфейса созданы. Правда потом, по моему, после столкновения с реальностью и проблемами производительности, туда в индусском стиле с помощью кувалды и медитации вколотили временные таблицы и вообще всякие SQL-фичи, которые с изначально overengineered ООП не особо совместимы, но хоть как-то по производительности тянут.

macklakov · 29.12.2016, 10:25

Цитата:

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

туда в индусском стиле с помощью кувалды и медитации

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

Цитата:

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

overengineered ООП

overengineered потому, что народ понятия не имел как работает сервер. Поэтому иерархия, вроде, навороченная, а по факту, логика скриптовая. На каждый чих запись в БД. Из-за этого много таблиц на которых локи возникают.

Цитата:

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

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

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

**fed** · 29.12.2016, 10:32

Цитата:

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

overengineered потому, что народ понятия не имел как работает сервер. Поэтому иерархия, вроде, навороченная, а по факту, логика скриптовая. На каждый чих запись в БД. Из-за этого много таблиц на которых локи возникают.

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

Ivanhoe · 15.12.2016, 11:12

А куча таблиц - уже смирился?

В целом нормально продается AX 2012, проекты есть. Со своей стороны могу заметить, что проекты крупнее стали, чем раньше, поэтому штучно, может быть, их стало чуть меньше. Плюс кризис подвел и Заказчиков, и ряд Партнеров.

**fed** · 15.12.2016, 11:39

Цитата:

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

А куча таблиц - уже смирился?

Ну они там явно переборщили с нормализацией и куча таблиц вообще лишена какого-то прикладного смысла (например InventTransOrigin*). Но жить с этим как-то можно, overhead при прикладной разработке небольшой. Мне, правда, кажется что это скорее к снижению производительности запросов привело, чем к ожидаемому росту. Но падение не очень большое - опять таки - жить с этим можно.
А вот распределения починить просто нельзя. Их можно только выкинуть из системы и забыть. Но кто же в Микрософте на это пойдет...