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

[Sancho]

Цитата:

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

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

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

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

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

[macklakov]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

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

[belugin]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

[macklakov]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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