Оver-engineering - "зачем так сложно?"

[trud]

Че-то мне кажется все гораздо проще - т.е. в разработку продукта приходят люди которые хотят показаться нужными и придумывают как-бы все переделать чтобы оказаться нужными
- АХ3.0 - карточка сотрудника - все поля(имя, телефон) в карточке (EmplTable), все круто, работают все фильтры, поиски, система насколько крута и удобна что продается Microsoft
- В АХ2012 - все говорят что это плохо, тормозит, много полей, вообще так никто базы не проектирует и все нафиг денормализуют(попутно удаляют и EmplTable, херя все возможности фильтрации и прочее)
- AX7 ранняя команда - понимают что с новой схемой никто работать не может, данные не загрузить, делают DataEntity где поля в одной строке
- D365 более поздняя команда - убеждают что текущий подход это полная ерунда, в дата енти куча ограничений и вообще дигитал трансформашн и делают новую базу
CDM, где все поля тупо в карточке сотрудника
-Попутно я так понял идут разговоры что вообще эта АХ очень сложна, язык какой-то странный, все тормозит, данные в интерфейсе разбросаны по разным формам, пользователи недовольны, поэтому начинается переписывание части функций на С# используя базу CDM. (это можно кстати уже посмотреть в работе подписавшись Dynamics 365 for Talent technical preview - пока напоминает больше студенческую лабу, но уже продают вовсю)

[mazzy]

Цитата:

Сообщение от 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#
да, студенческую лабу
да, уже продают.

но не потому что аксапта такая.
это общая попытка перейти от монолита к микросервисам. и не только в Аксапте. и не только в МС.

такой переход выполнялся многими. Тема перехода от монолита к микросервисам отрефлексирована и отхоливарена программистским сообществом по самое небалуйся.

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

[fed]

Цитата:

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

но не потому что аксапта такая.
это общая попытка перейти от монолита к микросервисам. и не только в Аксапте. и не только в МС.

такой переход выполнялся многими. Тема перехода от монолита к микросервисам отрефлексирована и отхоливарена программистским сообществом по самое небалуйся.

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

Есть такая классическая притча про стратегию, нежно любимая всеми кто проработал в Микрософте 10+ лет (Я так долго в MS не работал, конечно, мне ее в фейсбучную ленту занесло лайками старших товарищей):
"Один из лучших стрелков из лука в Японии однажды проходил, через одну деревню. И увидел, что кто-то стрелял из лука в мишень, и все стрелы попадали точно в цель. Рассматривая результаты стрельбы неизвестного стрелка, лучший мастер понял, что он не лучший. Достав меч для харакири, он хотел покончить с собой. Но местные жители, сказали, что это стрелял местный дурачок. Он сначала стреляет, а потом вокруг стрел рисует цель".

[ax_mct]

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Оverengineering - это проявление болезни программизма у 90%. Я очень сомневаюсь в том что в других условиях эти же программисты не будут страдать этой заразой. Поднявшись по служебной лестнице им и в голову не придет что перенос на .NET и переход на VS - это Оverengineering.
Если бы этой деформации реальности в мозгах технических специалистов не было - то и не случалось бы постановки таких задач и создания таких условий. Психическая Болезнь.

И не думаю что надо понимать и оправдывать ".NET программистов" к которым это попало в руки. Это не в один день случилось и начали это не "чужие", а "свои". Системные программисты АХ. Страдающие программизмом.

Цитата:

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

мысль понятна.
но чтобы получить ответ стоит сформулировать полностью: будет хуже кому? в чем выражается хужесть?

Хуже всем. Клиенту, партнеру, вендору.
Выражается в удовлетворении (куда входит и цена-качество) и в удобстве. Для всех участников.
То есть при отсутствии ненужных изменений в технической стороне как проявления Оverengineering в сознании специалистов всех уровней
нахождение на технической платформе 3.0 (к примеру) было бы лучше для всех участников эко-системы.
Все изменения абсолютно иррациональны и ни что иное как деформация сознания на всех уровнях и отсутствия чувства оverengineering. Даже в бизнесе это понимание простоты логики критически необходимо для успеха.

[egorych]

Цитата:

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

нахождение на технической платформе 3.0 (к примеру) было бы лучше для всех участников эко-системы.

Ну 3.0 - всеж сильно устарела, как технологическая платформа. 2009 - ИМХО самое то - и более-менее современные технологии можно просто использовать и идеологию не разрушили еще.

[Ace of Database]

Цитата:

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

Ну 3.0 - всеж сильно устарела, как технологическая платформа. 2009 - ИМХО самое то - и более-менее современные технологии можно просто использовать и идеологию не разрушили еще.

Когда МСу надоест заниматься ERP, с его стороны было бы очень красивым жестом отпустить Аксапту в свободное плавание в Open Source в том виде, в котором она была в AX2009.Да пусть даже и в том виде, как она была в AX3. Все-таки DirParty сильно напрягают, и еще самому себе делать assert в коде тоже напрягает. В АХ 3 было классно без assert'ов. Но в AX2009 пакетники лучше работают, чем в AX3.

[ax_mct]

Цитата:

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

Ну 3.0 - всеж сильно устарела, как технологическая платформа. 2009 - ИМХО самое то - и более-менее современные технологии можно просто использовать и идеологию не разрушили еще.

Платформа "устарела", "современные технологии" - это оно самое. Болезнь
"устарела" если нельзя полноценно CLR Interop
"современные технологии" - AIF, Sharepoint...

3.0 я привожу для чистоты примера. Да 2009 - лучше, но велика ли разница?
То что OCC, RecId, RPC и подобное это действительно kernel необходимое, и никак не часть "2009".
Но добавление что-то типа использования .NET service proxy, WCF - чистый воды програмизм.
AIF - чистый пример оverengineering.
Переход на Sharepoint EP - оverengineering.

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

Качество партнеров, рынок, проекты

Цитата:

Сообщение от George Nordic

Клиенту не нужен ни Х++, ни морфикс, ни слои - им на это, в общем-то, все равно. Им нужен продукт, который закроет их потребности, будет удобным и шустро работать, при этом - легко изменяемый под именно их потребности.

Вот все что прямо не направлено на закрытие потребностей клиентов, мешает удобно и шустро работать, усложняет изменение кода - и есть оverengineering как проявление дурной болезни.

[egorych]

Цитата:

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

Платформа "устарела", "современные технологии" - это оно самое. Болезнь
"устарела" если нельзя полноценно CLR Interop
"современные технологии" - AIF, Sharepoint...

3.0 я привожу для чистоты примера. Да 2009 - лучше, но велика ли разница?

По-моему очень велика! Хотя-бы при работе с памятью - АОС 3,0 при "наборе" 1,5Г памяти просто вешается. AIF и т.п. - это просто надстройки, а вот создать просто Web-сервис в 3.0 и 2009 - это 3 большие разницы.

[ax_mct]

Цитата:

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

По-моему очень велика! Хотя-бы при работе с памятью - АОС 3,0 при "наборе" 1,5Г памяти просто вешается. AIF и т.п. - это просто надстройки, а вот создать просто Web-сервис в 3.0 и 2009 - это 3 большие разницы.

При стандартной поддержке существующего эти kernel проблемы были бы решены в рабочем порядке.

А разница создания Web-сервис в 3.0 и 2009 - это программизм. Это вопрос новых классов/библиотек на уровне языка. Генерировать код можно на чем угодно.

[belugin]

Цитата:

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

придет что перенос на .NET и переход на VS - это Оverengineering.

Почему gподдерживать отдельную специальную более медленную виртуальную машину для X++ это не overengineering?

Почему поддерживать отдельную более бедную IDE для X++ это не overengineering?

Вон ABAP вполне себе на Eclipse живет (поправьте, если я что-то не так понимаю)

[ax_mct]

Цитата:

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

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

От того что мы расчленим эти 2000 строк (10 экранов?) на классы с использованием мощных паттернов и ненатурального ООП, а затем будем со всем этим искусстно бороться - ни продукту, ни клиенту не жарко и не холодно. Это программирование ради программизма.
Нет большой разницы 2000 это строк или 20 классов с точки зрения разных задач у вендора, партнера и клиента.
Нет такой проблемы как избыточность кода. Есть проблема у программистов которые смотрят на этот код.

Цитата:

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

Почему gподдерживать отдельную специальную более медленную виртуальную машину для X++ это не overengineering?

Почему поддерживать отдельную более бедную IDE для X++ это не overengineering?

Усилия и затраты по реализации нежелания поддерживать "отдельную специальную более медленную виртуальную машину для X++" и "отдельную более бедную IDE для X++" - в десятки и десятки раз превышают усилия и затраты по их поддержке.

Медленность нативного X++ это миф, бедность IDE - миф.
Скорость это железо, база данных и кэширование, бедность IDE - это плагины.

[mazzy]

Цитата:

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

Медленность нативного X++ это миф, бедность IDE - миф.

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

и дело даже не в портировании на .net/vs.
каждый помнит тормоза при первом обращении к AOT, при создании программисткого проекта. для глобальной компиляции аж специальную утилиту сделали.

про бедность - стоит вспомнить, что X++ основан на java-виртуальной машине первого поколения. когда никакого JIT, никаких оптимизаторов, тривиальный сборщик мусора, убогая модель объектов в памяти, чудовищно неэффективные exception и кривая релиазция tread, никаких функций высшего порядка. (тривиальный-убогий-неэффективный конечно по нынешним временам и по современным меркам).

сейчас актуальной является java 8 поколения. ближайшим будущим является java 9.

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

событий в morphX до версии акс7 существенно меньше, чем есть в операционках.
контролов современных не хватает.

не говоря уже про убогий отладчик.

==========================
не, morphX - отличная вещь для своего времени, хорошо продуманная и крепко сделанная.
но рано или поздно все-таки надо двигаться дальше.
и хорошо, что двигаются.

[ax_mct]

Цитата:

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

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

Спасибо за по существу. Но можно слушать пользователей, то есть не страдать аутизмом, но при этом продолжать болеть программизмом и в упор не видеть оverengineering.

Тормозов стало меньше? Что-то стало быстрее? Да на текущем железе оно летало бы.
Программировать стало легче?

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

оverengineering это когда нет чувства достаточности. Тот медленный и бедный нативный X++ был достаточен. Это как лопату усовершенствовать.

[belugin]

Цитата:

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

От того что мы расчленим эти 2000 строк (10 экранов?) на классы с использованием мощных паттернов и ненатурального ООП, а затем будем со всем этим искусстно бороться - ни продукту, ни клиенту не жарко и не холодно. Это программирование ради программизма.

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

Цитата:

Нет большой разницы 2000 это строк или 20 классов с точки зрения разных задач у вендора, партнера и клиента.
Нет такой проблемы как избыточность кода. Есть проблема у программистов которые смотрят на этот код.

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

Цитата:

Усилия и затраты по реализации нежелания поддерживать "отдельную специальную более медленную виртуальную машину для X++" и "отдельную более бедную IDE для X++" - в десятки и десятки раз превышают усилия и затраты по их поддержке.

Докажите.

Цитата:

бедность IDE - это плагины.

Вы непонятно выражаетесь. "Граальность" VS в том, что плагинов там большая куча

[Ace of Database]

Цитата:

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

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

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

[macklakov]

Цитата:

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

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

Типичный пример - счета-фактуры, книги продаж и покупок.
Сколько говорили про российскую специфику, про то, что их должны править задним числом. И т.п.

Нет, конечно accounting, в своей основе, более-менее похож везде. Но есть свои ньюансы. К примеру, как часто тебе приходилось настраивать рассчет себестоимости по LIFO? Или по каким принципам сейчас считается налог в Новой Каледонии? Как проводить взаимозачеты с клиентом в Китае, если и вы и клиент ведете бизнес в нескольких провинциях? Ну и всем нам знакомая корреспонденция, конечно. И этот самый счет фактура в какую сторону должен читаться? Слева-направо, сверху вниз? Или наоборот? Т.е. ядро ГК оно, конечно, почти всем подходит, а вот первичка...
И это банальные вещи, завязанные на местное законодательство. А есть же и новые бизнес-практики. К примеру agile компании, с взаимозачетами между подразделениями, оперативно перемещающиеся логистические хабы. Постоянно меняющиеся банковские и финансовые инструменты. Диктат со стороны бизнес-партнеров. Общая тенденция по переходу от торговли к аренде и сервисам.
Один поставщик не может за всем поспевать. "Универсальное" решение не сможет покрыть все варианты. А это означает, что таки придется отдавать значительные сегменты приложения на откуп сторонним поставщикам.