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

[artkashin]

По долгу службы дорабатываю решение на ASP.NET MVC, где куча кода закрыта в откомпилированных сборках, а для доработки, как раз и придумана возможность подписок, dependency injections на основе Unity и прочие гибкости которые предоставляет местный SDK.

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

Это просто очень медленно (раз в пять), работу стандартного кода не оттдебажить по-человечески, куча других неудобств, ну и по сути, не дает никакой гарантии, что при более-менее серьезном апдейте моя кастомизация не полетит к чертям.

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

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

[trud]

Цитата:

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

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

Вот кстати дискутировал на яммере по этому поводу. С точки зрения Микрософта копирование это совершенно валидный процесс.

Цитата:

Code duplication increases maintenance costs, but it at least doesn't break production.

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

[skuull]

Цитата:

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

Вот кстати дискутировал на яммере по этому поводу. С точки зрения Микрософта копирование это совершенно валидный процесс.

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

А как вы потом будите сводить их ? Скажем какой-то герой накопирует вам разного кода (вместе со стандартными багами), кастомизирует его, а потом добрый МС выпустит хотфикс в котором перепишит половину приватных методов которые вы скопировали и кастомизировали. Вы то об этом хотфиксе не узнаете, а когда узнаете надо будет как-то все это свести

[trud]

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