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

[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

Что-то стало быстрее?

ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора особенно если включена корреспонденция. Алгоритмические проблемы не решаются просто добавлением оборудования. Там кажется был o(n2) или типа того.

Интересно, что вы пишете очень категоричным тоном, не зная таких делалей но спрашивая о них

[belugin]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

Докажите.

Цитата:

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

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

[Ace of Database]

Цитата:

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

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

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

[belugin]

Цитата:

Сообщение от Ace of Database

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

Если бы там был метод в 2000 строк - было бы легче?

[macklakov]

Цитата:

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

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

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

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