Показать сообщение отдельно
Старый 15.06.2017, 00:21   #4  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от 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.
посмотрим.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 15.06.2017 в 01:11.
За это сообщение автора поблагодарили: S.Kuskov (5), Ace of Database (5).