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

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

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

(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% лучше, правильнее и главное надёжнее доработать саму конфигурацию. Проще отслеживать изменения.

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

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

(27) а не надо формы менять, все доработки форм делать кодом
а переделки в сложных случаях и так и так не избежать

(27) Нисколько сокращение не виртуальное. Если изменения в конфигурации затрагивают тот же модуль формы в месте, которое не дорабатывалось, то в расширении ничего не меняется, а в доработанной конфигурации надо заново восстанавливать все доработки.

(29)[а в доработанной конфигурации надо заново восстанавливать все доработки]
нужно, делает это за скромную плату ИжТиСи, два раза в год, при этом многократно упрощается работа 2 и 3 линии, кастомизация видна при сравнении с конфигурацией поставщика, а не в отладчике.

у меня например в ERP 3,5 тысячи точек отклонения, которые накопились за 8 лет =)

и цикл развития такой - между тех.релизами - расширения, ныряющие в тех.релиз