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

[skuull]

Цитата:

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

Выдернул из контекста с соседней темы чтобы ответить здесь по теме. Сделать можно что-угодно так или иначе. Вопрос то в том "зачем так сложно?". Это не уникальные грабли развития AX, все те же проблемы во всем программистском мире включая PHP.

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

Можете сформулировать критерий сложности? Потому что из ваших постов я понял его так: "Все что я не понимаю за 2 минуты - overengeneering". Людям пожилого возраста тяжело пользоваться мобильным телефоном, но это же не значит что мобильный телефон - overengeneering ?

[ax_mct]

Цитата:

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

...
Можете сформулировать критерий сложности? Потому что из ваших постов я понял его так: "Все что я не понимаю за 2 минуты - overengeneering". Людям пожилого возраста тяжело пользоваться мобильным телефоном, но это же не значит что мобильный телефон - overengeneering ?

В английском языке есть поговорка "дай человеку достаточно длинную верёвку и он на ней повесится" как аналог "дай дураку богу молиться он себе и лоб расшибет".

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

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

Критерии сложности такие же как и в механической инженерии.
Принцип KISS. Простота как условие популярности и выживания.

Привлекательность для реального мира ещё конечно.
Но в нем всегда привлекательно то что просто и элегантно.

[mazzy]

Цитата:

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

В английском языке есть поговорка...

Понесло-понесло...

Желающим поговорить об Оver-engineering вообще,
предлагаю переместиться в курилку
Оver-engineering - "зачем так сложно?" - Мортира Карл

Здесь обсуждение в разделе DAX:Программирование
Здесь давайте останемся к контексте аксапты.

Есть еще что сказать про Оver-engineering в Аксапте?

[ax_mct]

Цитата:

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

Есть еще что сказать про Оver-engineering в Аксапте?

Справедливо.

К примеру. Зачем был сделан рефакторинг FormLetter* фрэймворка ?
Почему - это но понятно, но ЗАЧЕМ??

Что именно стало легче, быстрее, проще?

В чем польза для быстродействия, надежности, функциональности и прочего от того что шестеренки стали мельче?

https://technet.microsoft.com/en-us/.../hh272871.aspx

[skuull]

Цитата:

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

К примеру. Зачем был сделан рефакторинг FormLetter* фрэймворка ?
Почему - это но понятно, но ЗАЧЕМ??

Есть внутренний документик в МС в котором написано: зачем, что плохо в старом, как новое хорошо и т.д. и т.п. В основном производительность и дублирование кода. За подробностями надо спрашивать людей имеющих к нему непосредственный доступ.

[mazzy]

Цитата:

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

Есть внутренний документик в МС в котором написано: зачем, что плохо в старом, как новое хорошо и т.д. и т.п. В основном производительность и дублирование кода. За подробностями надо спрашивать людей имеющих к нему непосредственный доступ.

о! а можешь название сказать? или прислать mazzy@mazzy.ru.
я попробую узнать можно ли выложить этот документик?

[ax_mct]

Есть White Paper
Using the refactored formletter framework
Date: May 2011
Author: Kenneth Puggaard, Senior Development Lead
http://go.microsoft.com/fwlink/?LinkID=218315

Обоснование
Because the FormLetter classes had so much functionality and no well-defined APIs in Microsoft
Dynamics AX 2009, they were complex for developers to understand and customize.

In Microsoft Dynamics AX 2012, the formletter framework has been refactored to clearly separate the
functionality needed for the posting process into different classes. This has led to a number of new
class hierarchies.

The Microsoft Dynamics AX 2009 base FormLetter class has been split into eight base classes. It also
has been changed to run under the SysOperation framework. Switching to the SysOperation
framework has the advantage of executing the code on the server tier during posting in IL
(intermediate language). Because of the switch to using the SysOperation framework, client callbacks
from code running on the server tier are no longer supported. Client callbacks result in an exception.

Вот сколько старый FormLetter существовал лет? Лет 10 все значит мучились.

Отчасти это редизайн из-за смены Runbase/RunBaseBatch на SysOperation framework.
https://msdn.microsoft.com/en-us/library/gg862488.aspx

SysOperation framework реализует MVC pattern. The isolation of the parameters (model), the dialog (view) and the code that runs (controller) is the essence of the pattern.

Model:
• Member variables
• Pack/unpack (aka serialization)

View:
• Dialog()
• GetFromDialog()
• PutToDialog()

Controller:
• Prompt()
• Run()

Ничего не имею против MVC вообще, но ЗАЧЕМ менять один код на такой же другой, я понять не могу.
Код - такой же. Его просто разбили на пазл паттерном.
Интерпретатору/компилятору - все равно, он все равно соберет все лоскутки в "простыню".
Пользователю - все равно.
Функциональности - все равно.
Программисту? Старым, после многих лет работы с этими классами - сплошная радость. Новым, быть они хоть трижды Java программистами - легче и проще это не делает. А типичные на клиенте - вообще не в состоянии понять.
Зато да, вот оно современное программирование какое

[fed]

Хочется номинировать на пример over-engineering новую главную книгу и любимые мной subledger/distributions.
Во первых - из за того что там очень высокий уровень абстракции, большая часть диагностики сводиться к сообщению "У нас тут какая-то фигня". После этого приходится тратить где-нить от часа до трех времени, чтобы протрассироваться и понять - где-же именно и какую настройку консультанты неправильно сделали. Просто благодаря могучим программистским механизмам, место возникновения ошибки отделено от его причины изрядным количеством вложеных вызовов,классов-фабрик, классов сохранения состояния, классов перехода состоянияи и тд и тп. Поэтому в момент обнаружения ошибки, выдать понятную диагностику просто невозможно. Проверку параметров в унаследованный от Дамгаарда код прогрессоры добавить не догадались.
Аналогично - процентов 85 эскалированных в Микрософт ошибок, приходилось на те самые замечательные распределения и сабледжер. При этом чтобы воспроизвести ошибки в стандарте и понять условия их возникновения, приходится тратить достаточно заметное время на трассированние исходного кода.
При этом, как я много раз уже писал, subledgers/distributions - это вообще абсурд, не связанный с экономической реальностью. Новая аналитика и ГК - конечно полезна в определенном числе случаев, но с другой стороны - в 98% случаев и старой ГК (как в 2009) хватало. (В том числе для вполне себе крупных внедрений enterprise уровня).

Наконец - хочу ввести критерий ovengineering: Это, как несложно было догадаться, отрицательный экономический эффект от изучения новой технологии. Вот я на эту борьбу с ГК и распределениями потратил, в общей сложности, порядка 4 недель жизни.
Во первых - далеко не все это время было billable. Клиенты как-то не очень рвутся оплачивать то, что с их точки зрения является ошибкой (не важно - нашей в настройках, или Микрософтовской - в коде).
Во вторых - эти знания мне вряд ли пригодятся для каких-то других задач, кроме собственно воспроизведения ошибок MS и поиска ошибок консов. (А это, как я уже заметил, не очень выгодные в финансовом плане и не очень интересные в профессиональном плане задачи). Я точно не буду создавать свой собственный вид source document и вряд ли я буду переписывать разноску в ГК.
Так что для меня изучение нового замечательного, богатого на новые программистские технологии модуля дало в целом негативный экономический эффект. Я потратил изрядное время на получение знаний сомнительной полезности и применимости.

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

[Pustik]

Цитата:

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

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

Если есть нетронутая SYS форма и твои изменения существенны то сдублировать ее - на мой взгляд разумно.

согласен, вообще с многим с вами солидарен, о чем вы говорите.

[Vadik]

Цитата:

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

Хочется номинировать на пример over-engineering новую главную книгу и любимые мной subledger/distributions

Ну а я тогда свою копеечку добавлю с бюджетированием. Там правда скорее не over-engineering, а просто уродский дизайн. Куча логики на вызывающих друг друга хранимых процедурах на T-SQL. Часть параметров с которыми эти SP вызываются (BudgetCheckGroup) - живут в рамках сессии и даже перехватив "падающий" вызов - оттрассировать его нельзя (это свежесозданные RecId которые при ошибке откатятся с транзакцией). Зашитый в код applock, из-за которого все проверки выполняются строго последовательно. Решил ты в одной компании проверить по бюджету журнал строк так на 10000 - все приложение встало колом. Ну не прелесть ли?

[skuull]

Цитата:

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

Есть White Paper
Using the refactored formletter framework
Date: May 2011
Author: Kenneth Puggaard, Senior Development Lead
http://go.microsoft.com/fwlink/?LinkID=218315

Это не тот о котором я говорил, перед тем как сделать фичу ее надо продать даже внутри МС. Вот кто-то и написал документ как плох текущий фреймворк и как хорошо он его переделает за n часов. Найти его можно было на внутреннем шарепоинте по словам formletter и refactoring/redisign.

[Raven Melancholic]

Цитата:

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

Хочется номинировать на пример over-engineering новую главную книгу и любимые мной subledger/distributions.

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

[mazzy]

Цитата:

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

Это не тот о котором я говорил, перед тем как сделать фичу ее надо продать даже внутри МС. Вот кто-то и написал документ как плох текущий фреймворк и как хорошо он его переделает за n часов. Найти его можно было на внутреннем шарепоинте по словам formletter и refactoring/redisign.

ага. вижу.
да, к сожалению, документ явно указан как конфиденциальный.

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

Цитата:

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

Есть внутренний документик в МС в котором написано: зачем, что плохо в старом, как новое хорошо и т.д. и т.п. В основном производительность и дублирование кода.

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

типа попытались реализовать концепцию "одно семейство - одна задача".

спасибо. надо подумать.

[Pustik]

Цитата:

Сообщение от Raven Melancholic

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

Да уж, сказать что просто немножко изменилось - ничего не сказать.

И у меня вопрос ЗАЧЕМ? Я пойму если объяснения будут адекватные. Типа стало быстрее, проще, ну или на худой конец все движется вперед - стоять на месте нельзя. Но только двигаться вперед можно и с учетом того , что было раньше сделано, а не по принципу "врач сказал резать, значит резать"

[skuull]

Цитата:

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

Программисту? Старым, после многих лет работы с этими классами - сплошная радость. Новым, быть они хоть трижды Java программистами - легче и проще это не делает. А типичные на клиенте - вообще не в состоянии понять.

Спорное утверждение, глядя лишь на название классов(*Create, *Post, *Print) уже понятно что они делают и где нужно дописать свой код.
Чем мельче и специализированней метод/класс, тем легче его тестировать. Хотя с пониманием как тестировать и как писать код который можно тестировать в АХ тусовке не сложилось

[mazzy]

Цитата:

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

глядя лишь на название классов(*Create, *Post, *Print) уже понятно что они делают и где нужно дописать свой код.

в теории конечно да.
но на практике получаются бесконечные *Adapter, *Handler, *Helper, *Util и прочие расширители.

тот же *Print здорово сбивает с толку, если в результате расширения функционал "печати" стал еще и отсылать куда-то email, обращаться к внешним EDI сервисам, или записывать что-то в базу данных... а если эти модифицированные потомки для работы еще и каких-то private-данных требуют, то начинается протяжка параметров через всю иерархию...

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

[fed]

Цитата:

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

Чем мельче и специализированней метод/класс, тем легче его тестировать. Хотя с пониманием как тестировать и как писать код который можно тестировать в АХ тусовке не сложилось

А ты попробуй продать реальному клиенту идею авоматизированного тестирования, покрытия кода тестами и тд и тп. Когда он узнает сколько это будет стоить,сразу
наступит ясность почему именно "не сложилось".
Вообще - автоматизированное тестирование окупает себя только на тиражируемом софте. Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно.
Только вот я пока не видел вертикальных решений аксаптовских с таким количеством клиентов (гм - может быть у add-ons типа Bartender или Formpipe Lasertnet есть такое количество клиентов). По крайней мере на обычных внедренческих проектах, с разработкой под конкретного клиента, разработка тест-скриптов не окупается.

[Vadik]

Цитата:

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

.. Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно

Это палка о двух концах. Да, найти незастолбленную нишу на 50+ клиентов - непросто. Но найти и застолбить ее с корявой, нетестируемой и нерасширяемой поделкой - еще тяжелее

Цитата:

А ты попробуй продать реальному клиенту идею авоматизированного тестирования

Такие идеи как мне кажется надо продавать инвестору, или ОЧЕНЬ "жирному" клиенту. И, да, типичные проектные финтифлюшки покрывать автоматизироавнными тестами пожалуй себе дороже будет

[ax_mct]

Цитата:

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

Но найти и застолбить ее с корявой, нетестируемой и нерасширяемой поделкой - еще тяжелее

Кто-то может сказать что с внедрением (в той или иной степени) автоматизированного тестирования
количество багов и последующих hotfixes стало меньше? Так сказать экономический эффект интересен.

Мне почему-то не кажется что в AX2012 или Operations стало меньше hotfixes по сравнению с к примеру 3.0. По моему как пользователи работали beta-тестерами так и работают.

Поправьте меня, так как не могу сейчас с цифрами в руках. У меня только субьективное впечатление от то здесь то там прочитанных KB и CU.

[Vadik]

Цитата:

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

Кто-то может сказать что с внедрением (в той или иной степени) автоматизированного тестирования количество багов и последующих hotfixes стало меньше?

Для 1611 на сегодня - чуть менее 600 X++ хотфиксов. Много это или мало ? Я не знаю, немало это точно, пускай половина и для проектов \ expense management \ GER которые мы пока не сильно (вернее практически никак) не используем. А сколько у Вас хотфиксов доступных, но не установленных - знаете ? У нас - вот столько (снимок с продуктива, там взяли небольшую паузу пока готовились на 1611 перескакивать, вот и поднакопилось). А сколько будет стоить их поставить, возьметесь посчитать? Предвосхищая реплики "да кому они нужны эти ваши хотфиксы" - нужны. У меня в этом году уже двум клиентам в Европе в связи с налоговыми заморочками вынь да выложь надо ставить хотфиксы для 2012 и 2009 которые за собой по древней традиции пол-аксапты тянут. При текущем уровне закастомизированности там одного code merge недели на две, я уж молчу про тестирование. И да - разработку придется остановить или вести параллельно в другом приложении и потом снова мерджить

Цитата:

Так сказать экономический эффект интересен

Ну вот возьмите среднюю ставку по консалтингу и посчитайте во что такие мероприятия выливаются. В D365O если разработка по уму организована - это в большинстве случаев скачать и импортнуть хотфикс, запустить проверку конфликтов (15 минут), запустить билд, сделать check in и можно начинать тестировать. Мелкие хотфиксы можно пучками ставить, просто чтобы глаза в LCS не мозолили
Я это все не к тому сейчас пишу, чтобы все всегда реализовывать максимально трудоемкими "программисткими" способами. Но в некоторых случаях эти усложнения оправданы