Доброго дня!
Как правильно внести код для облегчения последующего обновления: в Конфигурацию или в расширение?

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

Вот и думаю, если бы изменение было в Конфигурации было бы гораздо проще обновлять, нет?

(0) Универсальной таблетки нет.
Проще обновлять только тем, кто лучше разбирается в коде и не важно куда он вносил изменения. При внесении изменений делай подробную документацию для разработчика и оставляй внутри расширения или в комментариях кода. Будет проще потом, когда благополучно забудешь о том, что ваял

(0) Старайся не использовать &Вместо, это мина замедленного действия.
&ИзменениеИКонтроль вполне себе контролируется. Куда и как пихать от тебя зависит.
ОМ адаптируем только в конфигурации.

(2) ОМ расшифруй

(3) Общие модули же

(0) >>поставщик изменил процедуру, и когда я проверил возможность применения работы расширения вышла ошибка.

Это легко отслеживается с помощью проверки возможности применения и, с помощью утилиты сравнения (p4merge или KDiff3) изменения так же легко переносятся.

(2) у меня была процедура на форме.

(5) а ты как используешь p4merge с расширением?, насколько я понимаю, это же только для Конфигурации...

(5) это штатными методами отслеживается в платформе

(0) с чего вдруг оно проще в конфигурации
процедура изменена, значит в любом случае придётся ручками в неё залезть и внести изменения

(2) "ОМ адаптируем только в конфигурации"
почему?

(10) Обновлять проще

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

(0) кинь монетку - орел это расширение, решка - конфигурация
и почитай книгу "Дайсмен"

(13) Эта книга была крутой первые страниц 50, а дальше можно было не читать.

(12) Да, да. Давайте вынесем в расширения модули УчетОс, УчетМатериаловВЭксплуатации, а потом будем ебс тись с их сравнением с типовыми.

Это всё круто, пока 1С не выпилит целиком из общего модуля ту функцию в которой ты делал инъекцию, и тут функцию, которая её взывала, и сам общий модуль тоже.

Ну или вспомним тыгыдык с РН.СвободныеОстатки
Как пример "немного поменяли"

Если изменений много, то однозначно в расширение &ИзменениеИКонтроль

(14) тс точно пойдет, он столько вопросов задает вида "или-или"...

(16) В итоге они его потом вернули, под другим названием. Но цирк был тот еще.

Конечно, расширение. Прекрасно всё обновляется.
Особенности от типовых алгоритмов зависят.
1С начала менять состав процедур в некоторой области типовой, и от ИзменениеИКонтроль можно стало переходить к Вместо+Продолжить.

(20) Знаю точку зрения: Пока 1С не сделала возможным удобное сравнение/объединение модулей расширения с модулями конфигурации, расширение остается злом. А 1С этого никогда не сделает. Потому что расширения они создавали для себя, чтобы поставлять патчи. Как и многие другие механизмы они создают чисто для себя. И плевать они хотели на чаяния "программистов 1С".

(21)
Устаревшая точка зрения. Есть рабочие инструменты.
Коллега обновлением занимается. Всё у него быстро проходит.
Есть проблемы, когда 1С меняет состав процедур в алгоритме, но это затыкается тестированием. А доработка алгоритма в этом случае всё равно обязательна, что в расширении, что в конфигурации.

(22) он чем пользуется? этим?
https://github.com/xnd1124/CfeUpdater?tab=readme-ov-file

(23)
Вроде без этого, просто KDiff3.
Он показывал, но давно было, детали забылись.
Но процесс у него быстро идет, тестирование больше времени занимает.

(24) >> процесс у него быстро идет, тестирование больше времени занимает.

В этом и проблема.
Коллега просто переложил трудозатраты с обновления на тестирование. И хорошо, если все доработки покрыты автоматизированными тестами, и тесты эти правильно описаны. А то в большинстве случаев всё это счастье тестирования падает на пользователей.
Тестирование конечно никто не отменяет. Вне зависимости от того как дорабатывается конфигурация - расширениями или внутри. Но доработка расширениями превращает обновление в чёрный ящик. Когда контроль применения расширения промолчал, а доработка при этом может перестать работать. Просто из-а того, что разработчик поменял логику и расширенную (доработанную) тобой процедуру больше не использует, но оставил её "для совместимости". А пользователь тебе об этом расскажет через несколько месяцев, при сдаче отчётности, когда ему НДС или прибыль не свести из-за того, что допиленный тобою 5 лет назад регистр стал заполняться после обновления трёхмесячной давности по типовому алгоритму, а не так как ты когда-то доработал.

Расширения хороши для патчей, доработок сбоку (когда типовое решение и его бизнес-логика и алгоритмы не затрагиваются, а только дополняются) и для того, что раньше делалось как дополнительные отчеты и обработки. Для допиливания внутренних алгоритмов расширения годятся не более чем в 1-5%% случаев. В остальных 95-99% лучше, правильнее и главное надёжнее доработать саму конфигурацию. Проще отслеживать изменения.