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

[mazzy]

Цитата:

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

отношение к тому что есть оver-engineering кода в AX

нет, конечно. какие нафиг "отношения"?
разницу вносят очень технические и прагматичные моменты.

1.
прежде всего, кто должен реализовывать "защиту от дурака"?

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

если МС делает продукт для разработчиков партнеров/заказчиков,
то защиту от дурака должны делать эти разработчики партнеров/заказчиков.
следовательно код МС может содержать только happy path.
но стоимость внедрения и поддержки растет многократно.

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

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

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

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

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

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

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

• код - в котором задаются параметры расчета
• группа1 - которая содержит коды
• группа2 - которая также содержит коды

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

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

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

====================
4.
групповая разработка и мс-подход с Code owning, которого нет ни у заказчиков, ни у партнеров.
именно про Code owning писал Столлман в своем труде "Собор и Базар".
Code Owning очень сильно влияет на все, что разрабатывается внутри МС. прежде всего как системообразующий фактор, критерие-задающий фактор.

сообщество программистов вне МС пошло несколько другим путем - "форки можно и нужно создавать. форки создавать легко, не бойтесь создавать форки".
в сообществе программистов Code owner не может повлиять на форки административными методами. А при Сode owning - может.
Естественно, что самое легкое для owner'а - запретить трогать мой код. Поэтому при Code owning нужно затратить усилия, чтобы убедить owner'а.

Это не хорошо и не плохо. Это просто абсолютно другой подход.
С одной стороны, Code owning цементирует продукт.
С другой стороны, модули-дубли типа Основных средств, Расчет ЗП, Retail, WMS/WHS и прочий дубль-функционал появился именно как своеобразный форк в ответ на Code owning.

====================
и так далее.
каждый такой выбор в итоге дает спектр.

так уж получается, что сейчас "критерии лучшести" у разработчиков внутри МС сильно отличаются от "критериев лучшести", которые приняты у разработчиков партнеров и заказчиков.

возможно, различие - это побочный результат digital transformation.
хочется верить, что это различие проявилось в результате управляемого процесса.

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

[ax_mct]

Цитата:

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

нет, конечно. какие нафиг "отношения"?

разницу вносят очень технические моменты.

mazzy, спасибо за обстоятельный ответ. Особенно четко про Сode owning, форки и цементирование.

Все же думаю что есть пропасть между разными программистами Аксапты по отношению к оver-engineering вообще и в частности.

Одни приветствуют некий прогресс системы, а другие наоборот уверены что все эти технические изменения вредны. Лично я думаю что все эти "технические моменты" Microsoft сами по себе оver-engineering для того достаточно законченного продукта какой была Аксапта. На уровне самого наличия таких задач по изменению технической платформы до внесения чужеродного стиля и кода в X++.

Если сейчас брать не AX2012 (AX7 это слишком очевидный оverengineering),
а Аксапту 3.0 для внедрений как техническую платформу,
при условии того что в этой Axapta 3.0 тот же функционал как и в AX2012,
но при этом усилия были (пере)направлены на качество этого кода в рамках Axapta Best Practices
и продуманность функционала. Понятно что при этом какие binary фиксы но по сути на той технологической платформе.
То я совсем не уверен что будет хуже.

Любая привнесенная сложность которая не упрощает - оverengineering.
Что на уровне задач, что на уровне кода.

Более того ересь скажу. Атрибуты, делегаты, наследование интерфейсов и прочее подобное - суть есть оverengineering. Часто XML формат - оverengineering. Помогли? Облегчили что-то? Упростили? Сделали надежней или эффективней? Быстрее?

И я уверен что это таки мое отношение к оverengineering чувство и понимание которого у других явно другое. Понимание того что важно, а что нет.

Цитата:

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

.
...
Чем же занимается MBS последние лет 10? Чем угодно, но не введением модульности в продукт. Эпический перенос на .net, неистовый рефакторинг базы данных, революционными нововведениями x++. И при этом чем дальше тем сильнее приложение сплавляется в неразделимый клубок.
...

[macklakov]

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

Цитата:

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

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

Вот здесь программизм во всей красе расцветает. И в этом состоит "убийство AX". Вся идеология MorphX была в том, чтобы сделать предельно простой механизм для быстрого "допиливания" системы под нужды конкретной бизнес-практики. Ибо мир большой, везде разное законодательство, везде разные обычаи и они быстро меняются. Все предусмотреть невозможно. Более того, бизнес это война. Каждая компания пытается придумать инновацию, т.е. уникальный прием, который позволит обскакать конкурентов. Именно за это AX ценилась. Она позволяла довольно быстро и сравнительно дешево "допилить" бизнес-логику под конкретный бизнес. Да, механника была далека от идеала и создавала кучу технологических сложностей. И не так просто и легко было кастомизировать. Все равно были постоянные жалобы на недостаточную гибкость ситемы, которые пытались отмести лозунгом:"нельзя автоматизировать хаос" Но гораздо легче чем конкурентных продуктах.
И вот этого козыря AX уже почти лишили.
Эти постоянные попытки систематизировать бизнес-процессы, выстроить их в логические иерархии наследования. Сделать универсальный механизм, покрывающий все возможные бизнсе-сценарии. Это все симптомы аутизма. Иррациональное желание все систематизировать и разложить по полочкам, выстроить в единую логическую систему. Но этой единой логики нет! Есть огромное разнообразие законодательств, отраслевых договоренностей, сложившихся практик, видов контрактов. Если все свалить в одну кучу, то получается хаотическое нагромождение. Получается нечитаемая база данных. Получается нечитаемый код. Получается приложение, которое не подходит никому и при этом не дающее подстроться.
Эдакие универсальные кирзачи среднестатистического размера. Они всем или слишком большие или слишком маленькие, или слишком узкие или слишком широкие.

[belugin]

Цитата:

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

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

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

Цитата:

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

Причем ладно бы нельзя было бы сократить. Но и расширить тоже нельзя.

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

[ALES]

Цитата:

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

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

А вот с этого места поподробней..
Неужели уже при нынешнем поколении ожидания от системы у "продавцов", "заказчиков", "внедренцев" и "пользователей" совпадут? Произойдет ли качественный прорыв от "официального" распространения информации на уровне "чтобы включить фичу системы Х , вот в той форме включите опцию Y" (и "неофициального" понимания "для чего фича, как с ней работать", проектного опыта и желания им поделиться у "тренеров"\"внедренцев") до "в нашей системе принимать товар на конкретный склад надо так, инвентаризацию проводить на нем этак и одномоментно это делать нельзя, а с опцией Z так и вообще склад работать не будет" ? Или традиционно это все на уровне "тайных знаний" планируется оставить?