AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
All
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны Забыли пароль?

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 22.03.2017, 01:34   #41  
Egil is offline
Egil
Участник
 
1 / 35 (2) +++
Регистрация: 21.03.2017
Попробую и я вставить пять копеек в дискуссию со стороны 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 такой переход, конечно, будет гораздо тяжелее, но, думаю, и они не отстанут.
За это сообщение автора поблагодарили: ax_mct (10), mazzy (5), sukhanchik (5), dn (5).
Старый 22.03.2017, 02:55   #42  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
Сотрудники Microsoft Dynamics
 
1,830 / 696 (27) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от mazzy Посмотреть сообщение
Как правильно вести разработку в условиях, когда часть кода закрыта от изменения
Мне кажется, не с того конца к проблеме подходим. Система изначально спроектирована исходя из предположения что код открыт. Поэтому цеплять к ней extensions проблематично. Все слишком сильно переплетено и перепутано. Часть логики в классе, часть логики на форме, часть на таблице, часть вообще в макросах (не к ночи будут помянуты), часть в хранимках, часть в dll. И при этом четкого разграничения между модулями нет и интеграция дырявая. Тронешь проекты, надо заказы на продажу подкручивать. API задукоментирована сами знаете как и при этом довольно противоречива. Более того, традиционно локализации не поспевают. А для глобальных контор это большая проблема. Толку от американского функционала, если в новой каледонии новую систему налогообложения вводят?
Так вот, по правильному, конечно же, стоило бы переписать стандарт так, чтобы не было нужды ковыряться в мешанине. Четкое, хорошо задукоментированное API. И обновления по всему миру должны выходить с оперативностью 1С. Даже в регионах, которые с точки зрения объемов продаж, кажутся маловажными.
__________________
Isn't it nice when things just work?
За это сообщение автора поблагодарили: mazzy (2), ax_mct (10).
Старый 22.03.2017, 08:28   #43  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Most Valuable Professional
 
20,242 / 3058 (142) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от macklakov Посмотреть сообщение
стоило бы переписать стандарт так, чтобы не было нужды ковыряться в мешанине. Четкое, хорошо задукоментированное API. И обновления по всему миру должны выходить с оперативностью 1С. Даже в регионах, которые с точки зрения объемов продаж, кажутся маловажными.
базаров нет - лучше быть богатым и здоровым.
мало того, я бы даже сформулировал "вендор должен переписать" )))


Цитата:
Сообщение от macklakov Посмотреть сообщение
Мне кажется, не с того конца к проблеме подходим.
я предлагаю сразу пропустить тривиальные шаги и сформулировать тему следующим образом:

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


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

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

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

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

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

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

Последний раз редактировалось mazzy; 22.03.2017 в 08:42.
Старый 22.03.2017, 10:09   #44  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
MCBMSS
Злыдни
 
2,442 / 1521 (55) ++++++++
Регистрация: 13.06.2004
Адрес: Москва
Внесу еще немного соображений на тему обновлений.
Я разделяю обновления на 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 о регулярном (вплоть даже до ежедневном) обновлении.

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

Последний раз редактировалось sukhanchik; 22.03.2017 в 10:12.
За это сообщение автора поблагодарили: dn (6), belugin (3), gl00mie (3), ax_mct (10).
Старый 22.03.2017, 11:57   #45  
fed is offline
fed
Участник
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Ex AND Project
Соотечественники
 
1,999 / 3687 (126) ++++++++++
Регистрация: 13.03.2002
Адрес: İstanbul
Хочу поддержать sukhanchik. Когда-то давно писал о том что апгрейды ERP окупаются ТОЛЬКО если сам бизнес заказчика слишком изменился с момента внедрения.
А Микрософт как раз сейчас пытается продавать легкость апгрейда (крайне сомнительное преимущество с точки зрения клиента) в обмен на утрату контроля над приложением, утраты контроля за ключевыми бизнес-данными (в случае использования cloud), утраты контроля за будущими расходами (опять таки в случае cloud) и заметного увеличения стоимости внедрения (за счет более сложной и дорогой разработки и за счет гораздо более сложного исправления ошибок в production).
За это сообщение автора поблагодарили: ax_mct (10).
 

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход


Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 22:54.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.