Как правильно вести разработку в условиях, когда часть кода закрыта от изменения - 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 такой переход, конечно, будет гораздо тяжелее, но, думаю, и они не отстанут.

[macklakov]

Цитата:

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

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

Мне кажется, не с того конца к проблеме подходим. Система изначально спроектирована исходя из предположения что код открыт. Поэтому цеплять к ней extensions проблематично. Все слишком сильно переплетено и перепутано. Часть логики в классе, часть логики на форме, часть на таблице, часть вообще в макросах (не к ночи будут помянуты), часть в хранимках, часть в dll. И при этом четкого разграничения между модулями нет и интеграция дырявая. Тронешь проекты, надо заказы на продажу подкручивать. API задукоментирована сами знаете как и при этом довольно противоречива. Более того, традиционно локализации не поспевают. А для глобальных контор это большая проблема. Толку от американского функционала, если в новой каледонии новую систему налогообложения вводят?
Так вот, по правильному, конечно же, стоило бы переписать стандарт так, чтобы не было нужды ковыряться в мешанине. Четкое, хорошо задукоментированное API. И обновления по всему миру должны выходить с оперативностью 1С. Даже в регионах, которые с точки зрения объемов продаж, кажутся маловажными.

[mazzy]

Цитата:

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

стоило бы переписать стандарт так, чтобы не было нужды ковыряться в мешанине. Четкое, хорошо задукоментированное API. И обновления по всему миру должны выходить с оперативностью 1С. Даже в регионах, которые с точки зрения объемов продаж, кажутся маловажными.

базаров нет - лучше быть богатым и здоровым.
мало того, я бы даже сформулировал "вендор должен переписать" )))

Цитата:

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

Мне кажется, не с того конца к проблеме подходим.

я предлагаю сразу пропустить тривиальные шаги и сформулировать тему следующим образом:

Как вести разработку с минимальными в долгосрочной перспективе трудозатратами
в условиях, есть куча унаследованного кода И часть кода закрыта от изменения,
а платформа предоставляет систему событий и подписок?

Что должен внести в код вендор?
Какие техники и приемы может применять партнер/клиент?

=========================
пока прозвучали варианты:
= снять ограничения и писать поверх (лицензионным или нелицензионным способом)
= врезаться в существующие event'ы.
=== при этом ожидается что будет дублирование кода
=== один из крайних вариантов - полное дублирование - врезаться в событие "загрузка системы" и после этого не отдавать управление стандартному приложению

ограничения, насколько я понимаю:
= в закрытые объекты новые евенты добавить нельзя
= подписчик может не иметь доступа к паблишеру события, поэтому часть информации возможно придется передавать через глобальные переменные

доводы в пользу закрытого кода (см. жаркие холивары 90х и начала 2000х о закрытых/открытых системах):
= обновление на новую версию становится очень легким за счет усложнения первоначальной разработки и кастомизации

=========================
еще соображения?

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

[sukhanchik]

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

За все свое время знакомства с АХ с 2004 года - я постоянно слышу фразу, что что-то надо делать именно так, ибо это упростит / не усложнит процесс обновления. И что интересно - все разработчики / консультанты (в общем внедренцы) эту мантру постоянно повторяют. При том, что я ни разу не слышал эту мантру от директоров ИТ и представителей заказчика (за исключением ситуации, когда они это говорят со слов тех же внедренцев).
Т.е. когда покупают систему (я говорю на примере АХ) - никто даже в мыслях не рассуждает об обновлениях. Когда покупают MS Office / SQL Server / Visual Studio - то говорят - вот мы мол купили лицензию на 2010-й Office / 2010-ю студию и мы не можем ставить 2013-й офис или 2013-ю студию - т.к. на них нужна новая лицензия. Мы лучше поставим на новый комп то, что мы купили.

Ну т.е. бизнесу нужен инструмент, чтобы пользоваться. А не обновление ради обновления.
Многие из нас пользуются Word-ом на уровне какого-нибудь Word 2.0 / 97 и им этого хватает. Мы обновляемся только потому, что нас по сути заставляет это делать MS. Выпускаются новые компьютеры с новыми версиями ОС, которые плохо совместимы со старыми программами и мы вынуждены обновляться.

Как-то в свое время я общался с директором ИТ компании, в которой стояла AX 4.0, в то время как внедрения 2009-й уже активно "шагали по стране", а MS уже строил планы на AX 2012. Я спросил (естественно, с корыстными интересами) - а почему вы не хотите обновиться на 2009? И он ответил, что какой смысл обновлять только логотип системы, если мы не будем использовать все новые возможности новой версии? Т.е. зачем тратить деньги на то, что под флагом внедрения AX 2009 у нас будет стоять функционально та же AX 4.0? А если использовать все новые возможности - то это уже перевнедрение с реинжинирингом бизнес-процессов.

Общий смысл, который я хочу донести - не надо закладываться на какую-то эфемерную возможность обновления. Давайте посчитаем - сколько будет стоить обновление (работы по обновлению) и сколько будет стоить нам соблюдение некоторых правил, которые нам якобы упростят обновление. Будет ли стоить овчинка выделки?

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

И еще был пример. "Почему вы не хотите внедрить учет по МСФО?". "А зачем? Мне внедрение влетит в копеечку и затянется по срокам. Мне дешевле посадить девочку, которая за 2-4 недели вручную перелопатит все данные и построит отчет для аудиторов. А требуется мне это 1 раз в год".

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

Выводы из моего поста: Довод в пользу закрытого кода, как "упрощение обновления" - в рамках моих соображений - сомнителен. Естественно я рассуждаю с т.з. бизнеса. С т.з. вендора - само собой он упрощает работу самого вендора.

[fed]

Хочу поддержать sukhanchik. Когда-то давно писал о том что апгрейды ERP окупаются ТОЛЬКО если сам бизнес заказчика слишком изменился с момента внедрения.
А Микрософт как раз сейчас пытается продавать легкость апгрейда (крайне сомнительное преимущество с точки зрения клиента) в обмен на утрату контроля над приложением, утраты контроля за ключевыми бизнес-данными (в случае использования cloud), утраты контроля за будущими расходами (опять таки в случае cloud) и заметного увеличения стоимости внедрения (за счет более сложной и дорогой разработки и за счет гораздо более сложного исправления ошибок в production).

[Predatore]

Сейчас, только делать что-то рядом вклиниваясь на последней миле. Что мог бы сделать МС? Добавить самую малость ООП. Не обязательно внедрять всю парадигму целиком со всей её мощью и выразительностью. Достаточно реализовать хоть что-то отдалённо напоминающее наследование. Нужно поле 25 в таблице 17? Наследуйся и добавляй всё что душе угодно. Надо переопределить функцию из закрытого кодеюнита? Наследуйся и переопределяй на здоровье. Полиморфизм уже присутствует в зачаточном состоянии в виде переменных Variant, их ещё чуточку подкрутить, научить работать с родителями и наследниками и вообще в НАВе не будет не решаемых задач.
Ну а если всё это слишком сложно и кого-то сильно пугает. Можно слямзить такую штуку как partial. Она по сути своей элементарна как в понимании так и в реализации. Если в двух словах, то с помощью partial объект собирается из частей. На примере 17 таблицы, это может быть её закрытая часть, которую менять нельзя и сколько угодно открытых (каждый вендор может иметь свой кусочек с ограничением доступа для других вендоров), добавляющих к ней поля, функции, а начиная с 16 НАВика ещё и свойства. Когда же вы обращаетесь к ней в коде, вы видите цельную 17 таблицу, а то что она собрана из кусочков, это вас вообще не волнует.
Сделать можно много, главное захотеть.
P.S. Ещё бы очень хотелось поддержку если не классов, то хотя бы структур, но это я что-то совсем размечтался...

[Morpheus]

Цитата:

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

А Микрософт как раз сейчас пытается продавать легкость апгрейда (крайне сомнительное преимущество с точки зрения клиента)...

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

[Sancho]

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

[Logger]

Цитата:

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

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

Только это не ради обновлений, а ради сокращения срока поддержки продукта, чтобы им (MS) надо было поддерживать не зоопарк своих систем (2009, 2012 RTM, 2012 R2, 2012 R3, D365) со всеми их промежуточными внутренними KR, CU и.т.п.
А иметь одну версию D365 c коротким хвостом, который быстро сам подтягивается к голове (автоматические апгрейды). А кто не успел - тот опоздал (раз в 3 года топориком - хрясь)

Т.е. не смешивайте цель и средство.

Цитата:

Источник: https://community.dynamics.com/ax/b/...sibility-plans
==============
The Modern support policy provides three years of support for a release. Given this, overlayered code will continue to be supported in the Fall 2017 for three years.

[Predatore]

Цитата:

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

Только это не ради обновлений, а ради сокращения срока поддержки продукта, чтобы им (MS) надо было поддерживать не зоопарк своих систем (2009, 2012 RTM, 2012 R2, 2012 R3, D365) со всеми их промежуточными внутренними KR, CU и.т.п.
А иметь одну версию D365 c коротким хвостом, который быстро сам подтягивается к голове (автоматические апгрейды). А кто не успел - тот опоздал (раз в 3 года топориком - хрясь)

Т.е. не смешивайте цель и средство.

NAV 2009 уже давным давно не поддерживается, 2013 умрёт в следующем году.И что бы не произошло c NAV в будущем, это сильно вряд ли что-то изменит в этом плане. Тот же Office 2013 обновляется до Office 2016 даблкликом. И тем не менее поддержка Office 2013 заканчивается в следующем году.

Не путайте тёплое с мягким. Всё это нужно именно ради лёгких обновлений. Вернёмся к тому же Офису, что нужно для обновления? Купить лицензию или подписку. Последняя включает в себя все обновления на срок действия подписки. А дальше даже домохозяйка справится с обновлением. Всё, сделка завершена, считаем прибыль.
А что же в случае с NAV? Давайте самый печальный расклад рассмотрим, у клиента 2009 или что-то ещё более древнее. Что нужно для обновления? Всё та же лицензия с одной стороны, а с другой стороны: нуууу, вам нужно полное перевнедрение, которое вполне возможно выйдет ещё дороже чем внедрение. Как так? А вот так, мало того что системы сильно отличаются, так ещё и ваша кастомизация превратила систему в не поддерживаемого монстра.
Я бы медали из золота выдавал продавцам, которые бы смогли впарить обновление клиенту на таких условиях.

Главное - увеличить продажи, а никак не уменьшить срок поддержки, который всё равно не уменьшится.

[Logger]

Цитата:

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

Главное - увеличить продажи, а никак не уменьшить срок поддержки, который всё равно не уменьшится.

Так вроде ж в ссылке выше английским по белому написано про 3 года поддержки. Т.е. уменьшится.

[Predatore]

Цитата:

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

Так вроде ж в ссылке выше английским по белому написано про 3 года поддержки. Т.е. уменьшится.

Ссылка мёртвая.
И даже если поддержку сократят вплоть до 1 года, всё равно. Упрощение обновлений в первую очередь нужно для продажи этих самых обновлений.

[Logger]

Цитата:

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

Ссылка мёртвая.
И даже если поддержку сократят вплоть до 1 года, всё равно. Упрощение обновлений в первую очередь нужно для продажи этих самых обновлений.

Вот небитая:
https://community.dynamics.com/ax/b/...sibility-plans

Так теперь продаются не обновления, а подписка за пользование системой.

[fed]

Цитата:

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

Ссылка мёртвая.
И даже если поддержку сократят вплоть до 1 года, всё равно. Упрощение обновлений в первую очередь нужно для продажи этих самых обновлений.

Учитывая что они в облаке всех на подписку хотят перевести, вроде бы нету смысла особо напрягаться для именно продажи обновлений.
Кроме того, уже года 4 или 5 без покупки подписки на обновления невозможно покупать новых пользователей и новые модули. Так что я бы сказал - в Европе почти 100% заказчиков покупают подписку, но обновления не внедряют... Так что даже если on-premise версия будет продаваться по старой модели, реально ее без подписки использовать будет нельзя.

[Predatore]

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

[komar]

Цитата:

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

Ну и наконец, не стоит забывать, что продукты Dynamics движутся семимильными шагами по дороге в облака.

Цитата:

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

Мне кажется, не с того конца к проблеме подходим. Система изначально спроектирована исходя из предположения что код открыт.

ay, there's the rub

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

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

[Pavel]

Не знаю как теперь у MS (те просто не интересно), а раньше у Damgaard/Navision можно было в шеснадцатеричном формате в текстовом редакторе кое-что поправить и любой слой сделать 'нужным'... отредактировать и обратно вернуть в 'неприкосновенное')))))

[artkashin]

По долгу службы дорабатываю решение на ASP.NET MVC, где куча кода закрыта в откомпилированных сборках, а для доработки, как раз и придумана возможность подписок, dependency injections на основе Unity и прочие гибкости которые предоставляет местный SDK.

Код большинства "закрытых" сборок предоставлен для ознакомления, и если бы его не было, пришлось бы повеситься. Текущий мой подход:
В класс-наследник, который расширяет какой-то метод, я копирую код из оригинала (чтобы не сломать стандартную логику обработки), и правлю его уже так, как нужно мне.

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

Кто, вообще, утверждает, что апгрейды упростятся до уровня 1 кнопки?
Если более-менее серьезная кастомизация, а апгрейд содержит серьезные изменения базового функционала, будут неприятные килочасы по отлавливанию неожиданных багов. Причем в рантайме, а не на этапе компиляции.

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

[trud]

Цитата:

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

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

Вот кстати дискутировал на яммере по этому поводу. С точки зрения Микрософта копирование это совершенно валидный процесс.

Цитата:

Code duplication increases maintenance costs, but it at least doesn't break production.

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

[skuull]

Цитата:

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

Вот кстати дискутировал на яммере по этому поводу. С точки зрения Микрософта копирование это совершенно валидный процесс.

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

А как вы потом будите сводить их ? Скажем какой-то герой накопирует вам разного кода (вместе со стандартными багами), кастомизирует его, а потом добрый МС выпустит хотфикс в котором перепишит половину приватных методов которые вы скопировали и кастомизировали. Вы то об этом хотфиксе не узнаете, а когда узнаете надо будет как-то все это свести