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

[trud]

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

[skuull]

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

[trud]

Цитата:

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

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

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

[skuull]

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

Цитата:

After all, the methods are not private to disallow extension, they are private to hide implementation detail that we may want to change without notice, and that we cannot afford to have any dependencies on. Remember,, once we are sealed, we will never be able to touch things that are not private for binary compatibility reasons.

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

[mazzy]

Цитата:

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

А развавить можно систему лепя что-то сбоку

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

[trud]

Цитата:

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

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

О, сильно. я как-то пропустил эту цитату. ну простой пример - захотели вы перейти с таблицы Address на LogisticsLocation или LedgerTrans убрать. сбоку то тут не сделаешь никак.
т.е. конечно остается вариант - методы оставить но не использовать, но это то-же самое только сбоку

[fed]

Цитата:

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

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

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

[fed]

Уходя в несколько более позитивную тематику. Я тоже как запасной вариант думаю по поводу разработки в стиле Copy-on-Write. То есть - при необходимости внесения более или менее заметных изменений в любой стандартный объект, он тупо копируется, копируются объекты ссылающиеся на него и тд и тп, до тех пор пока мы, грубо говоря, не дойдем до пункта меню.
Я думал над схемой, при которой мы вначале внедрения добавляем весь стандартный микрософтовский код в репозиторий TFS, а потом заводим branch. (или как оно там в TFS называется?). В рамках этого бранча мы создаем вторые копии меняемых объектов и переименовываем их. А после того как Microsoft выпустит очередной хотфикс, мы просто коммитим их изменения в основную ветку, а потом мерджим изменения в нашу клиентскую ветку. Единственный вопрос, который у меня есть по этой схеме - а поддерживает TFS переименование объектов в бранче ? То есть - будет они понимать что мой файл с классом ABCReqCalc это на самом деле бранч файла ReqCalc? Просто в такой схеме еще можно будет как-то внедряться. Если же TFS таких вещей не позволяет, прогнозирую что микрософт конечно сможет легко обновлять свои классы, но клиент об этом не узнает. Стандартные микрософтовские объекты будут легко и регулярно обновлятся, но реальная бизнес-логика будет жить совершенно независимо от них. И партнер будет заниматься ручным мерджингом ТОЛЬКО если клиент наткнулся на конкретную ошибку, которая заведомо исправлена в последних обновлениях.
Также вангую что те клиенты, которые решаться установить сразу несколько вертикальных решений, будут с интересом наблюдать эдак три-четыре копии форм заказов или закупок. Интересно что микрософт будет делать в таких ситуациях...

[skuull]

Сольют топ менеджмент, не сольют топ менеджмент мы не знаем, можем только надеяться. Но внедрять то надо уже сейчас. Вся эта муть с continuous update часть одной большой стратегии МС и ради бедной ERP от нее никто не откажеться. Я правда не в курсе может где-то на виндовс\оффис\шарепоинт формумах идут подобные дискусии и все пророчат последнии деньки МС ?
Что делать сейчас ? Оверлеить по старинке и ждать что до весны 2018 всех разгонят, извенятся что были не правы и вернут все как было ?

[fed]

Цитата:

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

Сольют топ менеджмент, не сольют топ менеджмент мы не знаем, можем только надеяться. Но внедрять то надо уже сейчас. Вся эта муть с continuous update часть одной большой стратегии МС и ради бедной ERP от нее никто не откажеться. Я правда не в курсе может где-то на виндовс\оффис\шарепоинт формумах идут подобные дискусии и все пророчат последнии деньки МС ?
Что делать сейчас ? Оверлеить по старинке и ждать что до весны 2018 всех разгонят, извенятся что были не правы и вернут все как было ?

Ну поскольку у нас проект на Ax7 стартовал буквально неделю назад, я для себя вывел такое правило:
1. В простых ситуациях (на уровне копирования нового поля из закупки в накладную), делать через extensions
2. Все более или менее сложное делать через copy-on-write. В конце концов, если в итоге решат не блокировать разработку, замерджить изменения в оригинальный класс будет быстрее, чем в последний момент лихорадочно дублировать свои классы и создавать новые menuItem.
То есть - в целом, по моим наблюдениям, примерно в 65-70% случаев, в микрософте принимается решение делать все через Ж. Поэтому правильнее закладываться на худший сценарий из возможных.

[kashperuk]

А откуда вообще пошел слух про то, что Майкрософт может принять решение не блокировать разработку? Или это у вас wishful thinking?

[fed]

Цитата:

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

А откуда вообще пошел слух про то, что Майкрософт может принять решение не блокировать разработку? Или это у вас wishful thinking?

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

[trud]

Цитата:

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

Единственный вопрос, который у меня есть по этой схеме - а поддерживает TFS переименование объектов в бранче

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

идея то рабочая, но с текущими инструментами это огромный объем работы.
т.е. по сути то нужно то что в 2012 называлось upgrade project

[fed]

Цитата:

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

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

Кстати - не удивлюсь если на вас (в смысле - на Микрософт) там в суд подадут по какому-нибудь поводу. Например - за ненадледжащее оказание услуг по поддержке (типа - мы хрен знает сколько лет платили за подписку, а они выпустили продукт который дорабатывать нельзя, а без доработки оно у нас не внедряется). Или за отсутствие ценовой модели одноразового платежа - только с ежемесячной подпиской. (Типа - навязывание услуги.)
Вообще я тут уже писал где-то что схема cloud с подпиской начинает подозрительно напоминать налоги. То есть - ты их вынужден платить, ты не знаешь как они будут потрачены и будет ли результат их траты полезен тебе лично, ты не можешь быстро сменить юрисдикцию и сменить поставщика услуг и тд и тп. (При этом все-таки в Европе ты через систему выборов можешь как-то и до какой-то степени влиять на то как твои налоги будут потрачены, а в случае cloud ты просто платишь как рэкетирам).
Мой жизненный опыт говорит мне, что любое государство ОЧЕНЬ не любит когда кто-то пытается нарушить его монополию на сбор налогов. Поэтому я очень подозреваю, что любые иски против разнообразных монопольных облачных провайдеров будет очень положительно восприняты ЕСовскими органами.

[mazzy]

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

в этой ветке давайте сосредоточимся на технических аспектах.

Цитата:

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

Сольют топ менеджмент, не сольют топ менеджмент мы не знаем, можем только надеяться. Но внедрять то надо уже сейчас.

Цитата:

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

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

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

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

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

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

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

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

[skuull]

Цитата:

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

в этой ветке давайте сосредоточимся на технических аспектах.

Хотелось бы добавить еще 1 вопрос в список. Что делать ISV в этих реалиях ? Есть такие среди нас ?

[fed]

Цитата:

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

в этой ветке давайте сосредоточимся на технических аспектах.

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

[mazzy]

Цитата:

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

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

Имеет. И несколько. Я их перечислил.

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

Для принятия окончательного решения, стоит убедиться, что для данной системы определен оптимальное техническое решение.

Стоимость технических решений для текущих условий Dynamics будет велика.
Обрати внимание, что в этом никто с тобой не спорит.

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

[mazzy]

Цитата:

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

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

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

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

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

Предлагаю на обсуждение еще один вариант, который проявился в двух ветках:
Какие библиотеки используют разные веб-клиенты Dynamics?
Как достучаться из веб-приложения к акс2012, акс2009? Сервер OData?
Вариант - небольшие приложения, которые взаимодействуют с Аксаптой.

• В последнее время ориентир на веб-приложения. Даже приложения для мобильных платформ все ближе и ближе к обычным веб-приложениям.
• Сам майкрософт в своей поставке использует различные подходы-библиотеки для веб-клиентов.
• Сам майкрософт в своей поставке реализовал бизнес-логику вне Аксапты
• Процесс выделения "микросервисов" в майкрософте будет продолжаться и дальше

Поэтому, возможен такой путь:
Отдельное приложение может использовать DataEntity (AIF, DIXF) для обмена данными с Аксаптой, но бизнес-логику в своей области может реализовывать самостоятельно.

Да, тут теряется масса маркетинговых преимуществ типа "единая и всегда целостная база данных", "актуальные данные" и прочие лозунги вчерашнего дня.
Но появляются другие. Типа "гибкость" и т.п. )

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

Да, приложения вполне могут хостится не на windows-стеке, а на других серверах и платформах. Но в целом, Майкрософт может постараться сделать платформу и стек удобнее.

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

Что думаете?

[belugin]

Цитата:

Да, отдельные приложения - плохо с точки зрения архитектуры.

Почему? Для разных целей разная архитектура.

Цитата:

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

Тоже непонятно почему лучше для каких условий и зачем.

Отдельные приложения и экстеншены отличаются только разным API. Концептуально придется тоже дублировать код и в отдельных приложениях.

см. также
https://martinfowler.com/articles/mi...rade-offs.html
http://cloudacademy.com/blog/microse...tage-drawback/