Цитата:
Сообщение от
ax_mct
Все же думаю что есть пропасть между разными программистами Аксапты по отношению к оver-engineering вообще и в частности.
это те же самые программисты.
просто поставлены в другие условия. поэтому и критерии лучшести у них другие.
Цитата:
Сообщение от
ax_mct
То я совсем не уверен что будет хуже.
мысль понятна.
но чтобы получить ответ стоит сформулировать полностью: будет хуже кому? в чем выражается хужесть?
Цитата:
Сообщение от
macklakov
По мне, проблема в том, что навороченные паттерны применяются к бизнес-логике, которая, как уже говорилось, не может быть сложной. Она может быть очень разнообразной, но не сложной.
согласен в целом.
но паттерны применяются не к бизнес-логике, а к коду.
по идее код должен реализовывать бизнес-логику. по факту большая часть кода является технической, обслуживающей.
см.
AX2012. Цель атрибутов в расширении наследования классов
Цитата:
Сообщение от
macklakov
Вся идеология MorphX была в том, чтобы сделать предельно простой механизм для быстрого "допиливания" системы под нужды конкретной бизнес-практики. ... [AX] позволяла довольно быстро и сравнительно дешево "допилить" бизнес-логику под конкретный бизнес.
да. это была эпоха, когда Стив Балмер прыгал по сцене и кричал: Developers! Developers! Developers!
Сейчас продукты предназначены не для разработчиков.
И это не только аксапта.
И это не только МС.
Это общий тренд.
Цитата:
Сообщение от
macklakov
Эти постоянные попытки систематизировать бизнес-процессы, выстроить их в логические иерархии наследования.
Не, не, не, не!
Если бы попытки систематизировать бизнес-процессы... Это ж знать заказчика надо... Это ж надо концентрироваться на определенном сегменте. В то время, как планы продаж растут...
Постоянные попытки внести внутренние, технологические, девелоперские изменения,
которые уменьшают трудозатраты разработчиков МС при решении задач внутри МС в окружении и с инструментарием МС.
Цитата:
Сообщение от
macklakov
Сделать универсальный механизм, покрывающий все возможные бизнсе-сценарии.
Ну, не.
Нет такого. И не было раньше. И даже при Дамгаарде такого не было.
Цитата:
Сообщение от
macklakov
Есть огромное разнообразие законодательств, отраслевых договоренностей, сложившихся практик, видов контрактов. Если все свалить в одну кучу, то получается хаотическое нагромождение.
Знаешь, у меня и раньше было подозрение, что в разных странах в принципе одно и то же.
А теперь, когда напрямую поработал с запросами из разных стран, моя уверенность в том, что в основе стоят универсальные потребности, только увеличилась.
Да, валить все в одну кучу не надо.
Но и делать отдельные реализации, отличающиеся с точностью до названия, тоже фигово.
Типичный пример - счета-фактуры, книги продаж и покупок.
Сколько говорили про российскую специфику, про то, что их должны править задним числом. И т.п.
Оказывается, это паттерн:
1. на основании исходных проводок собрать данные в отдельную таблицу
2. дать возможность пользователю внести ручные правки в эту таблицу (да, включая вставку новых записей и включая удаление)
3. дать возможность пользователю утвердить
4. дать возможность напечатать/отослать утвержденное пользователем
5. дать возможность вносить коррекции/доп.листы в утвержденное
прежде всего, такой паттерн для withholding tax. и многих других данных в гос.органы.
реализации внутри аксапты отличаются только названиями (например, withholding tax или форма 1080), реализации отличаются валютами и курсовыми, некоторые реализации запрещают изменение исходных данных после утверждения, некоторые реализации пытаются интеллектуально построить корректировочную отчетность.
Цитата:
Сообщение от
macklakov
Эдакие универсальные кирзачи среднестатистического размера. Они всем или слишком большие или слишком маленькие, или слишком узкие или слишком широкие.
и портянки!
Цитата:
Сообщение от
trud
Че-то мне кажется все гораздо проще - т.е. в разработку продукта приходят люди которые хотят показаться нужными и придумывают как-бы все переделать чтобы оказаться нужными
Ну... не стоит привлекать злой умысел. Там такие же люди, что и везде.
Просто в условиях Code Owning транзакционные издержки проще снизить, тупо выделив себе отдельную область. Тогда можно не заниматься "непродуктивными" переговорами с Owner'ом, а просто сделать "как правильно". При этом, как Owner в этой области, ты можешь без объяснения причин просто послать каких-то странных людей, которые просят от тебя что-то незапланированного.
Простой критерий: снижение издержек и повышение продуктивности разработчика внутри данной команды. )
Остальное не учитывается.
Цитата:
Сообщение от
trud
- АХ3.0 - карточка сотрудника - все поля(имя, телефон) в карточке (EmplTable), все круто, работают все фильтры, поиски, система насколько крута и удобна что продается Microsoft
- В АХ2012 - все говорят что это плохо, тормозит, много полей, вообще так никто базы не проектирует и все нафиг денормализуют(попутно удаляют и EmplTable, херя все возможности фильтрации и прочее)
- AX7 ранняя команда - понимают что с новой схемой никто работать не может, данные не загрузить, делают DataEntity где поля в одной строке
- D365 более поздняя команда - убеждают что текущий подход это полная ерунда, в дата енти куча ограничений и вообще дигитал трансформашн и делают новую базу
CDM, где все поля тупо в карточке сотрудника
-Попутно я так понял идут разговоры что вообще эта АХ очень сложна, язык какой-то странный, все тормозит, данные в интерфейсе разбросаны по разным формам, пользователи недовольны
Кстати, хороший пример.
карточка сотрудника - считали что универсальные контакты (DirParty) позволит легче создавать разные продукты, которые совместно используют контакную информацию. Это было до того, как осознали проблему утечки персональной информации. Потребности пользователей вообще в расчет не принимались - ну, сделаем же необходимые инструменты.
DataEntity - позволит легче создавать разные продукты, которые совместно используют общую информацию. Потребности пользователей в расчет не принимались - ну, сделаем же необходимые инструменты для пользователей.
CDM - позволит легче создавать разные продукты, которые совместно используют общую информацию. Но механизмы чуток другие... Потребности пользователей?... Кто здесь?!!
АХ действительно сложна и полна исключений и дублирующего функционала.
Но общий подход - рефакторинг - предполагает, что кто-то потратит время и разберется с существующим. После чего возьмет на себя ответственность за изменение функционала. А вдруг этот кто-то недоразберется и изменит что-то нужное? См. те же DirParty и DataEntity... И какой смельчак-начальник поставит свою карьеру на кон для решения этой задачи? Вот и добавляются исключения в существующем коде. Вот и появляется дубль-функционал "для отдельно взятой бизнес-задачи". Вот и появляются атрибуты для узкой области применения.
Цитата:
Сообщение от
trud
поэтому начинается переписывание части функций на С# используя базу CDM. (это можно кстати уже посмотреть в работе подписавшись Dynamics 365 for Talent technical preview - пока напоминает больше студенческую лабу, но уже продают вовсю)
да, начинается переписывание на C#
да, студенческую лабу
да, уже продают.
но не потому что аксапта такая.
это общая попытка перейти от монолита к микросервисам. и не только в Аксапте. и не только в МС.
такой переход выполнялся многими. Тема перехода от монолита к микросервисам отрефлексирована и отхоливарена программистским сообществом по самое небалуйся.
Для меня все еще загадка - почему МС почти во всех вопросах считает себя первопроходцем и почему при вопросе "как сделать" не выполняется первое действие "посмотреть как сделали другие". Причем это касается и кода в Аксапте, и стратегии, и политики продаж. Либо я чего-то не понимаю.