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

**mazzy** · 20.03.2017, 09:25

в прошлой ветке я не получил ответ на свой вопрос
Как правильно выполнять unit-тестирования методов с параметрами по умолчанию на ваш взгляд?

но зато получилось сформулировать коренное отличие продуктов dynamics от традиционных средств разработки:

часть кода закрыта от изменения.

в аксапте это sys-слой и невозможность изменить сигнатуры методов. сигнатуры можно только расширить параметрами по умолчанию.

в навике это закрытые codeunit'ы. для которых конечно была партнерская лицензия за туеву десятков тысяч евро. но и она открывала доступ не ко всем кодеюнитам, насколько я помню.

в MS CRM это система extensions. к подобной системе идет и Аксапта, кстати.

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

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

= в аксапте этот метод находится в слое sys. его сигнатуру нельзя менять
= в навике, насколько я помню, этот метод находится в закрытом codeunit'е
= в MS CRM - не знаю. но подозреваю, что расширение доступно только через extension

можно взять любой другой метод для примера.

jopagames · 20.03.2017, 12:32

Дык, правильный ответ уже написан в самом вопросе.

Цитата:

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

в навике это закрытые codeunit'ы. для которых конечно была партнерская лицензия за туеву десятков тысяч евро. но и она открывала доступ не ко всем кодеюнитам, насколько я помню.

Всё остальные способы - от лукавого

Обсуждение "полупиратских методов", насколько я помню, на этом форуме не приветствуется.

Другое дело, что иногда действительно ВОТ НУЖНО бывает создать в таблице 17 поле с номером 25 (ну, или удалить поле 24)
И хрен какая партнёрская лицензия (даже самая дорогая) даёт это сделать в этой таблице и в этом диапазоне.

ЗЫ: Но, вообще, основное в этом вопросе - открыть объект.
Т.е. всё же превратить его в текст, изменить, перекомпилировать и закатать обратно.
Таких способов есть несколько.

Будем обсуждать их здесь, Сергей?

**mazzy** · 20.03.2017, 12:51

Цитата:

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

Будем обсуждать их здесь, Сергей?

А других способов совсем нет?

Если так, то пока достаточно констатации - только открыть. возможно применив reverse engineering.

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

ax_mct · 20.03.2017, 16:47

Цитата:

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

Что на ваш взгляд должен сделать майкрософт, как поставщик продукта, чтобы разработка была эффективной?

Как минимум реализовать поддержку Interceptor and DI паттернов. Понять что мир программирования уже ушел далеко от классического ООП. И то классическое и святое ООП несовместимо с потребностями возникающими при создании расширений. Даже если приукрасить это прямоугольное OOП с помощью делегатов и подписки на события. Не та гибкость.

Interceptor pattern - это перехват методов позволяющий полностью их заменить.
https://en.wikipedia.org/wiki/Interceptor_pattern
http://docs.oracle.com/javaee/6/tutorial/doc/gkedm.html
http://stackoverflow.com/questions/1...ors-in-java-ee

DI - Dependency injection - это подход позволяющий встраиватьcя.
https://en.wikipedia.org/wiki/Dependency_injection
https://ru.wikipedia.org/wiki/%D0%92...81%D1%82%D0%B8

P.S. Справедливости ради в том или ином виде это есть в .NET в отдельных технологиях и библиотеках, но я не критикую MS в "отсталости", а говорю о реальной доступности применения как инструмента в конкретных наших по сути фреймворках. Когда инструментарий не соответствует потребностям.

**mazzy** · 20.03.2017, 17:07

Цитата:

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

Как минимум реализовать поддержку Interceptor and DI паттернов. Понять что мир программирования уже ушел далеко от классического ООП. И то классическое и святое ООП несовместимо с потребностями возникающими при создании расширений. Даже если приукрасить это прямоугольное OOП с помощью делегатов и подписки на события.

Да, согласен - лучше быть богатым и здоровым, чем бедным и больным.

А как это эффективно и правильно сделать в существующем инструментарии?
И с существующим унаследованным кодом?

Цитата:

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

Поделитесь,
= какие приемы эффективной разработки вы используете?
= Какие плюсы и минусы у закрытого кода в вашей системе?
= Что на ваш взгляд должен сделать майкрософт, как поставщик продукта, чтобы разработка была эффективной?

belugin · 20.03.2017, 18:35

Что приходит на ум:

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

2. Заменять более крупными кусками (Можно посмотреть на SubledgerJournalizerBondExtension - вместо того, чтобы как-то встроится в системную группровку, заменяет ее полностью). Плюсы - больше можно сделать, минусы - дублирование кода, надо протаксивать что-то при фиксах в расширяемом коде.

3. Грязные трюки (например рефлекшн для доступа к приватным методам, Moles) - Плюсы - больше возможностей чем 1. меньше кода чем в 2.. Минусы - сломается при апгрейде.

Вообще говоря, вся штука в том, чтобы вендор мог выделить такие интерфейсы которые:
1) Были бы достаточны для расширяющих
2) Сам вендор имел практическую возможность их не ломать.

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

Вопрос в том, чтобы отделить одно от другого.

Интересен также подход в опенсурс проектах - большинство софта пишут используя API но если надо чего-то еще, то можно предложить патч (насколько я знаю, даже MS патчил линукс, чтобы поддержать Hyper-V), если патч будет хорошим (по стандартам кодировния, документированным) то есть вероятность что его вольют в версию продукта.

**Sancho** · 20.03.2017, 21:21

Цитата:

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

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

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

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

о!
ну и галочку в настройке "погодная скидка включена" по умолчанию - нет.
вот теперь да. как-то так.

macklakov · 21.03.2017, 03:41

Цитата:

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

с ошибками, потому что сварганена на скорую руку.
не оттестирована на пельмешках в зной и семечках при штормовом ветре.

Что-то я не понял откуда это вытекает. Почему кастомный функционал обязательно на скорую руку и с ошибками?
P.S. идея метеорологической скидки/наценки, кстати, довольно интересная.

belugin · 21.03.2017, 09:00

Цитата:

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

Что-то я не понял откуда это вытекает. Почему кастомный функционал обязательно на скорую руку и с ошибками?

Мне кажется, тут не обязательно, а вероятностно. У меня как-то сформировалось убеждение, что, чисто статистически, чем выше слой, тем хуже код

.

Может быть из-за того, что менее оправданно дорого разрабатывать, если пользователей меньше

belugin · 21.03.2017, 08:58

Цитата:

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

т.е. после всего стандарта одной строкой делаем вызов собственной функциональности.

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

**mazzy** · 21.03.2017, 09:38

Цитата:

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

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

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

macklakov · 22.03.2017, 02:55

Цитата:

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

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

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

**mazzy** · 22.03.2017, 08:28

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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

**Артем Enot Грунин** · 21.03.2017, 10:41

В случае с CRM дело обстоит сильно иначе. У нас нет внутреннего языка, или возможности править поведение системы, как таковое. Все что у нас есть, с точки зрения серверной логики - это плагины-обработчики событий системы. Технически, мы можем перехватить попытку чтения цены продукта и заменить выходное значение в своей логике, но на практике так не делается. Системные механизмы используют множество согласованных обработчиков, логика которых не документирована. На практике, если не подходит стандарт - делаешь рядом что-то свое. Победить и изменить - как правило, себе дороже. Но это в общих чертах, конечно. Бывают случаи проще, там можно доработать стандарт, если можно на него опираться, а не менять в корне.

**mazzy** · 21.03.2017, 11:08

Цитата:

Сообщение от Артем Enot Грунин

с точки зрения серверной логики - это плагины-обработчики событий системы.

event'ы?

т.е. поставщик кода должен заранее предусмотреть места для таких обработчиков-событий? и задокументировать их. так?

тогда можно жить и вести разработку и в закрытой системе. так?

**Артем Enot Грунин** · 21.03.2017, 15:48

По сути да, это эвент ресиверы. Есть воронка обработки события, куда можно встроиться на разных этапах, в том числе и до вызова системной логики. Приблизительно 99% событий доступны для обработки, но мы не можем отключить обработчики от MS. Максимум "исправить" то что они сделали. Так работать можно, модель рабочая. Но, как я говорил, в каких то случаях, проще написать свое

ax_mct · 21.03.2017, 13:53

Цитата:

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

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

Цитата:

Сообщение от Артем Enot Грунин

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

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

Вендор не просто меняет способ разработки по техническим причинам в D365FO, он тупо закрывает разработку функциональности вообще со стороны партнеров и клиентов. Всякие точки расширения и события - это пластмассовая косточка с клубничным вкусом. Пососать.

Событий и подписок - недостаточно.
Нужна возможность замены любых классов и методов целиком. Через конфигурационные файлы. Но это будет тот же overlayering по своей сути.

**mazzy** · 21.03.2017, 14:12

Цитата:

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

Всякие точки расширения и события - это пластмассовая косточка с клубничным вкусом. Пососать.

Ой, все. Страдать пожалуйста сюда: Клуб анонимных оверлейщиков

Цитата:

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

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

Возможно. Замечание принимается.
Уточню название темы:

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

что должен сделать вендор?
что может сделать партнер/заказчик своими силами?

ax_mct · 21.03.2017, 14:32

Цитата:

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

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

что должен сделать вендор?
что может сделать партнер/заказчик своими силами?

Каким бы нехорошим не был подход с рефлексией, но он заслуживает серьезного внимания.
https://ievgensaxblog.wordpress.com/...xtension-code/

X++:

using System.Reflection;
 
/// <summary>
/// Handles events raised by <c>SalesLineTypeEventHandler</c> class.
/// </summary>
public class SalesLineTypeEventHandler
{
    [PostHandlerFor(classStr(SalesLineType), methodStr(SalesLineType, insert))]
    public static void SalesLineType_Post_insert(XppPrePostArgs _args)
    {
        SalesLineType salesLineType = _args.getThis();
 
        var bindFlags = BindingFlags::Instance | BindingFlags::NonPublic;
 
        var field = salesLineType.GetType().GetField("salesLine", bindFlags);
 
        SalesLine salesLine = field.GetValue(salesLineType);
 
        if (salesLine)
        {
            salesLine.MyNewField = 42;
            salesLine.doUpdate();
        }
    }
}

Вендор же никому ничего не должен

**mazzy** · 21.03.2017, 14:43

Цитата:

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

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

Да, заслуживает.
Но рефлексия - это тут же уход в динамическое программирование взамен статической компиляции. Со всеми плюсами и минусами.

И соответствующими холиварами на эту тему )))

Цитата:

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

Вендор же никому ничего не должен

это тоже неправда )))
но должен он очень мало чего и мало кому. это так.