|
14.06.2017, 15:16 | #1 |
Участник
|
не, не делимся на два.
или распределяемся по спектру, согласно критериям лучшести ))) Цитата:
Сообщение от mazzy
На самом деле все проще.
Как и остальные люди, специалисты в МС хотят сделать лучше, проще, быстрее. Просто "критерии лучшести" в МС сильно отличаются от остальных людей. Можно много говорить на тему "почему отличаются". Это отдельная тема. Но как бы то ни было, получаются решения типа советских панельных домов. Которые получались неудобными для жилья, очень затратными в части отопления, дорогими в части перевозки (панелевоз всегда ездил порожняком со стройки в сторону панельного завода). Но зато сроки строительства минимальны и стоимость производства панелей минимальна за счет массового производства, а удобство-отопление-перевозки не включались расчет при оптимизации. |
|
14.06.2017, 23:03 | #2 |
Banned
|
Цитата:
Обозначим две стороны. Старые пердуны которые не понимают зачем в Аксапте нужно общепринятое искусство программирования и другие, те кто прочитал "Искусcтво программирования Кнута" до конца. Первых раздражает технико-программистская эволюция Аксапты, а вторые наоборот это приветствуют. Спектр спектром, но есть четкий водораздел - отношение к тому что есть оver-engineering кода в AX. Для меня это любой код который я не понимаю в течение трех секунд и любой дизайн который мне интуитивно непонятен как программисту Аксапты. "Зубная боль... Зачем" (с) Более того если увижу 2000 строк в одном месте - ругаться не буду. Да, это under-engineering но на практике это может быть и дешевле чем оver-engineering когда этот код разбит на пол-сотни классов обслуживающих не бизнес-логику, а междусобойчик паттернов кодирования. При этом конечно могут быть и ситуации когда overengineering в коде возникает не при обслуживании маньячества самого программиста, а при реализации overengineered бизнес-логики. Когда постановщик задачи - тоже матмех закончил Цитата:
Сообщение от fed
Мы занимаемся автоматизацией бизнес процессов. Заметная часть участников этих самых бизнес процессов - люди весьма среднего образования и интеллекта. Поэтому все слишком сложно спроектированные бизнес-процессы, с течением времени либо упрощаются либо умирают.
Поэтому для меня использование в X++ коде слишком большого числа паттернов говорит о том что бизнес-проблема изначально неправильно сформулирована. |
|
15.06.2017, 00:21 | #3 |
Участник
|
нет, конечно. какие нафиг "отношения"?
разницу вносят очень технические и прагматичные моменты. 1. прежде всего, кто должен реализовывать "защиту от дурака"? если МС делает продукт для конечных пользователей, то защиту от дурака должны делать разработчики МС. любой, кто делал системы для пользователей, знает, что код для happy path это, как правило, очень простой и небольшой код. а защита от дурака - это много-много дурацкого кода. если МС делает продукт для разработчиков партнеров/заказчиков, то защиту от дурака должны делать эти разработчики партнеров/заказчиков. следовательно код МС может содержать только happy path. но стоимость внедрения и поддержки растет многократно. если защиту от дурака не делает никто, то код получится очень простым. но нужно будет очень сильно вложиться в обучение пользователей. ==================== 2. инструментарий. внутри МС используется очень много хороших инструментов для контроля кода, для тестирования кода и интерфейса, для развертывания среды для разработчика и консультанта, для мониторинга, для групповой работы. эти инструменты накладывают определенные ограничения. в частности, атрибуты у методов не характерны для аксапты, но очень характерны для инструментов автотестирования. всякие моки-автозаглушки, тестовые данные и т.п. в частности команда Макса Белугина работает над проектом, который очень сильно оторван от интерфейса аксапты, но задевает достаточно глубинные механизмы. Я все ждал, что Макс сам расскажет об инструментарии. но раз он молчит, значит время еще не пришло. ==================== 3. Сценарии работы. Уж не знаю к счастью или к сожалению, но в МС сейчас одержимы идеей "пользовательских сценариев". грубо говоря, некто продумывает "как будут работать пользователи" и это становится священным писанием, которое нельзя изменить. Причем ладно бы нельзя было бы сократить. Но и расширить тоже нельзя. Зачастую можно сделать более общую реализацию, которая не только покрывает все придуманные пользовательские сценарии, но и открывает массу новых возможностей по использованию. Но эти открытые возможности надо описывать, надо покрывать тестами и заниматься прочим геморроем. Поэтому самой простой для разработчиков МС выход - не расширять пользовательские сценарии. Типичный пример, реализации в Аксапте, которая открыла новые возможности - реализация расчета налогов, комиссионных вознаграждений, процентов и т.п. Изначально разработчики дали три сущности:
сам алгоритм - и тривиальный, и мощный. И не побоюсь этого слова - декларативный. Используется как паттерн много где в Аксапте. Алгоритм очень понятный в настройке и поддержке. но надо предусмотреть как, в каких местах должны "встретиться" разные группы. и что делать, если пересечение содержит больше одного кода. поэтому алгоритм плохо расширяемый. поскольку количество комбинаций для "встречи" растет как факториал числа групп. Исповедуя же "пользовательские сценарии" не добиться подобных красивых реализаций. Пользовательские сценарии диктуют процедурную реализацию, в которой прописан шаг за шагом. А если добавить к этому еще и "защиту от дурака" + требования инструментария... то и получается интуитивно непонятный дизайн. ==================== 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. посмотрим. Последний раз редактировалось mazzy; 15.06.2017 в 01:11. |
|
|
За это сообщение автора поблагодарили: S.Kuskov (5), Ace of Database (5). |
15.06.2017, 02:16 | #4 |
Banned
|
Цитата:
Все же думаю что есть пропасть между разными программистами Аксапты по отношению к о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++. И при этом чем дальше тем сильнее приложение сплавляется в неразделимый клубок. ... |
|
15.06.2017, 04:37 | #5 |
NavAx
|
По мне, проблема в том, что навороченные паттерны применяются к бизнес-логике, которая, как уже говорилось, не может быть сложной. Она может быть очень разнообразной, но не сложной. В это же время, ядро, где дизайнерски и архитектурные патерны более чем применимы, все еще страдает наследием 90-х.
Цитата:
Сообщение от mazzy
Зачастую можно сделать более общую реализацию, которая не только покрывает все придуманные пользовательские сценарии, но и открывает массу новых возможностей по использованию.
Но эти открытые возможности надо описывать, надо покрывать тестами и заниматься прочим геморроем. Поэтому самой простой для разработчиков МС выход - не расширять пользовательские сценарии. И вот этого козыря AX уже почти лишили. Эти постоянные попытки систематизировать бизнес-процессы, выстроить их в логические иерархии наследования. Сделать универсальный механизм, покрывающий все возможные бизнсе-сценарии. Это все симптомы аутизма. Иррациональное желание все систематизировать и разложить по полочкам, выстроить в единую логическую систему. Но этой единой логики нет! Есть огромное разнообразие законодательств, отраслевых договоренностей, сложившихся практик, видов контрактов. Если все свалить в одну кучу, то получается хаотическое нагромождение. Получается нечитаемая база данных. Получается нечитаемый код. Получается приложение, которое не подходит никому и при этом не дающее подстроться. Эдакие универсальные кирзачи среднестатистического размера. Они всем или слишком большие или слишком маленькие, или слишком узкие или слишком широкие.
__________________
Isn't it nice when things just work? |
|
|
За это сообщение автора поблагодарили: S.Kuskov (5), Pustik (2), Stitch_MS (3), Logger (1), olesh (1). |
15.06.2017, 22:34 | #6 |
Участник
|
Цитата:
Цитата:
3.
Сценарии работы. Уж не знаю к счастью или к сожалению, но в МС сейчас одержимы идеей "пользовательских сценариев". грубо говоря, некто продумывает "как будут работать пользователи" и это становится священным писанием, которое нельзя изменить. Причем ладно бы нельзя было бы сократить. Но и расширить тоже нельзя. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
19.06.2017, 21:41 | #7 |
Участник
|
Цитата:
Сообщение от mazzy
====================
3.Сценарии работы. Уж не знаю к счастью или к сожалению, но в МС сейчас одержимы идеей "пользовательских сценариев". грубо говоря, некто продумывает "как будут работать пользователи" и это становится священным писанием, которое нельзя изменить. Причем ладно бы нельзя было бы сократить. Но и расширить тоже нельзя. Неужели уже при нынешнем поколении ожидания от системы у "продавцов", "заказчиков", "внедренцев" и "пользователей" совпадут? Произойдет ли качественный прорыв от "официального" распространения информации на уровне "чтобы включить фичу системы Х , вот в той форме включите опцию Y" (и "неофициального" понимания "для чего фича, как с ней работать", проектного опыта и желания им поделиться у "тренеров"\"внедренцев") до "в нашей системе принимать товар на конкретный склад надо так, инвентаризацию проводить на нем этак и одномоментно это делать нельзя, а с опцией Z так и вообще склад работать не будет" ? Или традиционно это все на уровне "тайных знаний" планируется оставить? |
|
15.06.2017, 21:53 | #8 |
Участник
|
Цитата:
Так что для каждого отсутсвием овержнжиниринга был бы разный уровень избыточности кода. |
|
Теги |
sysoperation framework |
|
|