Как правильно вести разработку в условиях, когда часть кода закрыта от изменения - Sys-слой в аксапте, закрытые codeunit в навике, extensions в MS CRM

[Egil]

Попробую и я вставить пять копеек в дискуссию со стороны NAV. Начну, пожалуй, с моего видения плюсов закрытого кода. Я как раз сторонник мнения, что открывать всё и сразу не стоит. Базовый код приложения лучше держать закрытым от изменений. Разумеется, при условии наличия эффективного инструментария для доработок другими методами.
Основной минус закрытого кода вполне очевиден - вследствие невозможности изменения кода приходится изыскивать сложные решения там, где в открытом коде проблема решается простейшей модификацией. Вместо того, чтобы открыть дизайнером объект, считающий скидку, и добавить один фильтр на таблицу, мы начинаем изобретать велосипед и дублировать логику.
Плюсы этого подхода, как водится, есть обратная сторона минусов, поскольку быстрые решения вида "сейчас две строчки тут подправлю, и всё заработает" имеют нехорошее свойство просто перекладывать проблему в другое место и другое время. И доводы ниже - это скорее ловушки модификации кода, от которых предостерегает запрет изменений.

1. Исправления багов в C/AL коде NAV выпускаются в виде ежемесячных кумулятивных апдейтов. Каждый апдейт - это просто текстовый файл со всеми объектами, изменёнными за прошедший месяц. Если в соответствующих объектах в вашей базе нет кастомизаций - нет и проблем с накатыванием апдейта. Объекты импортируются, компилируются, и работа продолжается. При этом даже минимальные изменения в пользовательской базе требуют ручной работы. А объект, переписанный до неузнаваемости, превращает рутинную механическую задачу в новую разработку с сопутствующим тестированием. В результате с высокой
вероятностью хотфиксы в кастомизированные объекты будут импортироваться в лучшем случае выборочно, исключительно для сценариев, непосредственно затрагивающих бизнес-процессы клиента - по принципу "когда жареный петух клюнет".

2. Аргумент второй - апгрейд базы на новую версию. Проблемы те же, что и в первом пункте, но в гораздо больших масштабах, плюс дополненные трудностями миграции данных. Обширная кастомизация легко превращает апгрейд (который в идеальном мире должен быть задачей пусть сложной и ответственной, но технической), в новый проект внедрения.

3. Ну и наконец, не стоит забывать, что продукты Dynamics движутся семимильными шагами по дороге в облака. А SaaS и кастомизация вообще совмещаются крайне сложно и с громким скрипом. Если облачным сервисом пользуются десять клиентов, и каждый из них требует считать скидку по-своему, каждая из десяти модификаций потребует наличия отдельной базы. И все проблемы с интеграцией кода можно смело умножать на количество баз. Расширения (extension package), основанные на событиях, не встретятся с такими сложностями. В multitenant архитектуре расширение импортируется на нужный tenant - только для клиента, которому
оно необходимо. Базовый код приложения при этом остаётся без изменений, кастомизации работают на отдельных тенантах.

Если вернуться к вопросу о том, как же нам посчитать скидку во враждебных условиях закрытого кода, то решение уже было описано выше. Поскольку паттерн interceptor разработчикам NAV пока недоступен (да, быть богатым и здоровым, несомненно, лучше), то выход остаётся один - перехватывать инициативу после того, как базовый код приложения посчитал скидку, и заменять результат на свой. Кодюнит Sales-Calc. Discount для этого предоставляет событие OnAfterCalcSalesDiscount. Аналогичное событие OnAfterCalcPurchaseDiscount есть в Purch.-Calc.Discount.

К вопросу о том, как разработка поставлена в Европе / США vs СНГ. В европейских странах (Германия, Великобритания, к примеру) и Штатах NAV распространён гораздо больше, чем в России. Но там и смысл, вкладываемый в аббревиатуру SMB, несколько отличается от российского понимания этого термина. Гораздо больше компаний, которые покупают NAV действительно как коробочный продукт - без модификаций или с минимальными изменениями скорее косметического характера. У таких клиентов больших проблем с модификациями не возникает. Те же, кто покрупнее и могут себе позволить лицензию за много тысяч денег и штат разработчиков (как альтернатива - регулярно платить партнёру за доработки), зачастую попадают в ту же ловушку глубокой кастомизации - до сих пор работают на шестой версии и с грустью отгоняют печальные мысли о неизбежном апгрейде.
Именитые ISV (к примеру, Lanham, Cosmo Consult / Tectura) активно работают над переносом своих решений на модель extension package. Для монстров вроде LS Retail или Incadea такой переход, конечно, будет гораздо тяжелее, но, думаю, и они не отстанут.