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

[macklakov]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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