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

[sukhanchik]

Цитата:

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

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

Ну тут-то как раз как мне кажется просто. Если я дублирую функциональность, то ... я ее в программном плане не дублирую, а реализую лишь уже то, что реализовано в узком смысле, то, что нужно мне. Всяко функциональность заказов на продажу будет больше по объему функциональности моего "акта об оказанных услугах". Я еще могу "облениться" и просто нарисовать свой интерфейс, который даже напрямую в General Journal* не будет лазить, а просто будет создавать ЖГК.
Т.е. быстро, просто и под меня. С т.з. программного кода - там даже и не будет пахнуть идеей заказов на продажу. С т.з. философии системы / Best Practice - это неверно. Но... проблему с обновлениями я решил. А с лицензией - еще надо как-то доказать, что мои Task-и "заслуживают" Enterprise . Конечно, если я явно буду использовать ЖГК - то наверное это будет явно и видно. А вот если я задействую лишь архитектуру АХ... то на архитектуре как бы не стоит тип пользователя

В общем - MS-у мне кажется придется прописывать какие-то более четкие правила использования типов лицензий (используешь в коде класc DimensionStorage - все, значит Enterprise. Пишешь ручками джойны - Task) ))))))))

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

[komar]

Цитата:

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

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

Цитата:

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

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

ay, there's the rub

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

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

[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).

[Morpheus]

Цитата:

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

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

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

[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]

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

[Sancho]

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

[Predatore]

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

[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 можно обойти с помощью дублирования объектов.
при этом клиент может собственно продолжать с легкостью ставить обновления от Микрософта, большие модификации в форме заказов не мешают этому.

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

[trud]

ну это типа в их понимании "increases maintenance costs". этого никто и не обещал что будет легко, обещали беспроблемную установку обновлений от микрософт
кстати почему только приватных, public то методы тоже наверное будут меняться при переходе между версиями, интересный момент кстати.

[skuull]

Ну вопервых, как мы поняли из дискусии с МС про использование рефлексии для вызова приватных методов - микрософт микрософту рознь, одни говорят низя, а вторые можно. Кто вам конкретно про копирование сказал ? может опять какой-то необразованый контрактор
А паблики не будут сильно меняться как только App Suite залочат, об этом какраз говорят, что сейчас они все пихают в приваты чтобы иметь возможность менять этот код без оглядки на обратную совместимость.

[trud]

Цитата:

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

А паблики не будут сильно меняться как только App Suite залочат, об этом какраз говорят, что сейчас они все пихают в приваты чтобы иметь возможность менять этот код без оглядки на обратную совместимость.

ну вот это кстати интересный момент. т.е. если не менять public методы - по сути то это значит не развивать систему. во всех переходах между версиями (самое показательное ах2009-ах2012) очень много пабликов довольно значительно менялись.
Думаете развитие продукта остановят?

[fed]

Цитата:

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

Ну вопервых, как мы поняли из дискусии с МС про использование рефлексии для вызова приватных методов - микрософт микрософту рознь, одни говорят низя, а вторые можно.

Умиляет вера в наличие у Microsoft стратегии и вообще кого-то с пониманим того что правильно, а что неправильно.
В теории, на этот вопрос должен был бы отвечать архитектор продукта (тот же Эхренберг например). Проблема в том, что он последние 15 лет ничем кроме балабольства не занимался, и на любой вопрос будет отвечать разговорами про IoT, Cortana Intelligence Suite, Disruptive Innovations и тд и тп. Также одними из стейкхолдеров являются политические фигуры в лице нынешнего топ-менеджмента Dynamics, которые подписались сделать автоматически обновляемую систему, а что с нею будет дальше их не колышет (поскольку есть надежда уйти с повышением). Поэтому вопросом "Как правильно?" они даже не задумываются. Есть, конечно же, вменяемые персонажи, с реальным опытом участия во внедрениях, которые хорошо понимают что без серьезного дописывания и переписывания, в любом более или менее крупном клиенте не внедрить. Поэтому эти персонажи точно также как и мы, ждут пока нынешний топ-менеджмент Dynamics сольют. Ну и на вопросы по поводу копирования отвечают в стиле:"<Если наш нынешний отмороженный менеджмент действительно заблокирует слои,то> Вы можете копировать классы, хотя это конечно повысит стоимость сопровождения". (Естественно - часть в угловых скобках просто подразумевается). Наконец, есть какое-то количество бывших разработчиков MS Office (условно говоря), которые специфики ERP-бизнеса не понимают и действительно верят что Ax можно внедрять с минимальными изменениями. Они естественно отвечают что копировать классы не хорошо (что для их модели мира вполне разумно).