Добрый день Господа и Дамы.
Уже долгое время меня терзает вопрос. Почему все программисты вокруг используют расширения к типовому функционалу конфигураций? Это же жутко не удобно. Но со мной никто не согласен. Попробую подробней описать суть моего негодования.

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

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

Вы используете расширения при работе?
Спасибо.

3. Не использую.

Я согласен, но я использую расширения для правки багов на лету.

И там, где доработок немного.

Нужно просто с умом подходить.. для каких-то задач расширения очень даже.. а для каких-то лучше не использовать, вот и всё.

Использую.

как-то так , они имхо, для этого и нужны

Не добавляю данных в расширение, не использую &Вместо.

расширения - хорошо.
но типовые мало приспособлены для расширения кода
слишком много процедур "все в одном"

ТиИ все еще грохает данные в расширении или уже поправили баг?

думал снова Гений ветку создал

(9) Фиксин тоже не любит расширения?

(0) кури аннотацию &ИзменениеИКонтроль​

(0) Использую. Да есть конфузы с БСП. Но все реже его стали использовать.

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

(14)

При должном подходе, расширения хороши, есть определенные сложности, но с новыми релизами платформы работать комфортнее и комфортнее.

(0) Использую, где это уместно

(11) Вы пробовали это использовать это в реальности например в форме документа НачислениеЗП в ЗУПе 3.1? Это в разы увеличивает трудозатраты на обновление. Просто в этом документе последние 2 года постоянно тусуется колода из процедур функций для заполнений данными.

(11) Честно говоря не использовал эту аннотацию. Надо попробовать.

А какие альтернативы?

Как-то так

(20) Переходить на 7.7 естественно. Восьмерка сырая.

(0) Использую полноценно. Есть нарекания - если форма в расширении "протухла", то при попытке открыть ее и обновить крашится платформа, приходится обновлять форму немного по-другому. С ЗУП-м вроде все неплохо работает. Старые расширения с &Вместо по мере обновления меняю на &ИзменениеИКонтроль​, ИМХО, красиво все получается. Хотя, стараюсь без фанатизма - реквизиты ТЧ в документы и новые регистры накопления не добавляю, пока необходимости не было.

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

(0) Кому неудобно?

В механизме расширений конечно пока еще остаются заметные неудобства для разработчика (например связанные с невидимостью нерасширенных объектов метаданных конфигурации в средствах разработки). Но он уже сильно помогает сократить затраты на обновлениях при небольших доработках конфигурации поставщика. Большие доработки все же разумнее делать в самой конфигурации.
Также механизм расширений позволил делать универсальные подсистемы легко динамически подключаемые/отключаемые к основной конфигурации.

Нормально делай – нормально будет

Я данные в расширениях не храню, а вот подправить код поставщика без снятия с поддержки дорогого стоит.

По моему удобно. Часто использую результат продолжить вызов.

(0) &ИзменениеИКонтроль
https://wonderland.v8.1c.ru/blog/razvitie-mekhanizma-rasshireniy-konfiguratsii-15/

(30) +

После появления (30) вносить изменения и отслеживать - одно удовольствие

У расширений конечно куча минусов.
Например когда их много разных на одной конфе то дорабатывать становится ахтунгом.

(20) А какие альтернативы?

Полиморфизм

Расширения постоянно дорабатываются. Пользоваться ими становится все удобнее

(0) 3 системы только на расширениях

Уже встречал базы с десятком, а то и больше расширений. Не понравилось. Сам стараюсь, новые объекты добавлять в конфигурацию, а не в расширение - это не влияет на обновления. Движения меняю, по-возможности, подписками. Отчеты и обработки делаю внешние. Расширения использую, если надо изменить форму. Если надо внести существенные изменения в алгоритмы, предпочитаю не расширения, а в самой конфе - проще отслеживать, что там 1С очередной раз изменит в своих алгоритмах...

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

Все реквизиты в основную конфу, остальное, по возможности, в расширения. Стараюсь по максимуму обойтись без &Вместо. Есть пара расширений полностью самостоятельных (в них реквизиты тоже в расширении). Из того, что сильно напрягает в использовании расширений это, пожалуй, только то, что ЖР не знает про объекты созданные в расширение и пишет в себя всякую фигню.

Расширение - это для доработок тех, кто не хочет слазить с типовой, т.е. для мелких фирм.
Что-то серьезно дописывать расширениями - мозг сломается.

(0) Полностью поддерживаю высказанную точку зрения. Со всеми описанными проблемами (или очень похожими) мы сталкивались в том или ином виде.
Однако выводы из проблем применения расширений у нас несколько иные.

Каждую доработку конфигурации надо очень осторожно реализовывать через расширение. Таким образом, чтобы предусмотреть любые возможные изменения вносимые поставщиком (1С) при обновлениях.
Когда речь идёт об изменении какого-либо ключевого функционала, например, в общих модулях расчета з/п в ЗУП или в подсистемах НДС в БП, делать это следует исключительно в самой конфигурации. Никаких расширений! Потому что в лучшем случае при обновлении что-то вывалиться с ошибкой (например, несоответствие количества параметров в расширенной нами процедуре), а в худшем ошибки может не возникнуть, но наш допиленный функционал начнёт работать не так, как это было заложено. Произойти такое может из-за того, что 1С решит вдруг по-другому рассчитывать какие-либо данные, которые изменяются нами в расширении или используются, как исходные. Об этом нам потом может налоговая инспекция сообщить в требовании.

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

Правильный ответ на голосовалку: п.4 Используем, но частично и очень осторожно.
Выбираю п.3 только из солидарности с автором ветки.

(0) расширению нет альтернативы в тяжёлых и распределенных системах с высоким коэффициентом готовности,
используем с удовольствием, переносим в тех.релизы по мере подготовки,
ясен пень, данные в расширениях не храним

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

Очень даже норм.
Но пока без добавления данных.

(0) Не согласен! Все наоборот, обновление не тронутой конфигурации раз в 100 быстрее, небольшое расширение поправить значительно быстрее.
Сделали бы еще перекомпиляцию расширения "на лету", было бы еще проще.
Ну и "Когда несколько лет назад появились расширения" они были совсем ущербные.
Некорректно сравнивать "несколько лет назад" и "сейчас".
Добавление данных не использую, выкручиваюсь на доп.реквизитах и т.п.

(45) Да, так удобнее. Или с помощью всяких оберток делать. Есть очень старые обработки котрые 1С может если только выкинуть типа Загрузки из 7.7. Вот в них удобно использовать расширения несмотря на то что их вряд ли кода нибудь обновят

Правило по одно:
1. ОМ править в конфигурации
2. Реквизиты создавать в конфигурации
3. В расширениях - макеты, формы с программным добавлением реквизитов, патчи.
Плюс перехват типовых п/ф и вызов своих, проще сравнивать.

Расширения скоро будут удобными.

Очень удобно

Использую. Есть сложности и их не мало. На первый взгляд выигрышь немного больше, но детально не анализировал.
Надеюсь, что все проблемы, с которыми сталкиваюсь сейчас в ближайшем будущем будут решены. Все же это довольно молодой и интересный механизм.

Использую, но не везде.
Свои реквизиты - от греха подальше в основную конфу. Вроде бы сейчас и в расширении корректно работают - но пока что еще не совсем доверяю...
Полноценные отдельные блоки и подсистемы (не универсальные, без тиражирования) - в основную конфу.
Тиражируемые - в расширения.
Формы - программная правка в расширениях (лучше через расширение переопределяемого общего модуля).
Подписки, движения в типовых документах - добавляются в расширении.
Все доработки по возможности - "дополнением к типовым алгоритмам", например - надо дополнить возвращаемую коллекцию типовой функцией еще одной колонкой - лучше ее отдельно дозаполнить в конце, чем влезать в процедуру построчного заполнения и т.п. &Вместо - по возможности только в комбинации с "ПродолжитьВызов()"; если так не получается - то через &ИзменениеИКонтроль.
Все никак не дойдут руки написать "шаблоны" на программную доработку запросов с помощью объектной модели - пока запросы в основном дорабатываю через "СтрЗаменить"; в расширение включаю, если получается в режиме &Перед/&После ...
И да, если единственный способ доработки - это 100500 правок по несколько строк в одной процедуре - то лучше такие изменения внести напрямую в конфигурацию...

(51) СтрЗаменить в запросе субъективно работает быстрее, чем разбор схемы запроса и доработка программно.

(23) >>приходится обновлять форму немного по-другому. тоже сталкивались, поделитесь технологией обновления?

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

Использую. Удобно. Но надо привыкнуть

(0) Полноценно, но &ИзменениеИКонтроль​ иногда глючит :-/

Яркий пример на 8.3.16 переношу процедуру в расширение, не переносит объявление локальных переменных, копирую ручками. Какие-то процедуры ни в какую не принимает, ругается "модуль изменился", сравниваю тексты вижу отличия только в #Вставка ... #КонецВставки, ругаюсь, делаю &Вместо и жду одобрения перехода на новый релиз платформы.

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

Прикольный пример выбран. Мне вот интересно, а если без расширения навалять в типовую ЗУП 3.1 изменений в глобальных модулей - это что решит проблему в разы лучше, чем через расширение?

(58) Если было принято решение перелопатить ЗУП 3.1 вдоль и поперек, то, возможно, без использования расширений их будет поддерживать менее трудоемко. Если доработки очень маленькие, то тогда лучше через расширения.
На личном опыте могу сказать, что в ЗУП 2.5 у меня были изменения, которые я со временем забодался в процессе каждого обновления поддерживать. Постепенно их становилось все меньше. При переходе на ЗУП 3.1 изменения уже были в таком количестве и такие, чтобы обновление сводилось к нажатию на клавишу "ОК" несколько раз.

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

(60) А мне почему-то кажется, что с учетом резких телодвижений при реализации переходов с 3.0 на 3.1, с 3.1.5 на 3.1.8, затем -> 3.1.10 -> 3.1.14 ...
Ну возможно и есть какие-то иллюзии ... Только это уже чисто религиозные некие предпочтения, на уровне двухперстия староверов

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

Если конфа на поддержке у стороннего вендора, то конечно стараюсь юзать расширения, если это возможно

Сдуру можно и *** сломать. В меру и к месту и без фанатизма.

В полной мере. Структура метаданных меняется в самой конфигурации

Нет моего варианта. Я использую, только если важно сохранить обновление без моего участия. Либо подправить ошибку (костыль нарисовать) в типовом решении.
А если разработка полноценная - то меняю основную конфигурацию.

Нид хелп
8.3.17.1549, ЗУП 3.1.14.129
Выношу процедуры формы в расширение с директивой  &ИзменениеИКонтроль
добавляю в код
#Вставить
мой код
#КонецВставить

получаем ошибку на выходе "Ожидается оператор препроцессора #<<?>>Вставить

Механизм рабочий вообще?

ясно, в описании одно, по факту - другое, вопрос закрыт

ощущение, что &ИзменениеИКонтроль кривоват в работе. Другой вопрос
Делаю небольшую вставку
#Вставка
//комментарий вставки
код вставки
#КонецВставки

в режиме предприятия появляется ошибка, что в расширении "Текст модуля изменился" о_О
Проверка возможности применения расширения вываливает ошибки с действием "Восстановить соответствие с методом конфигурации". При нажатии на действие - "Объединение с помощью внешней программы не настроено"
ватафак?

"бонжур, епта", неужели это реакция на добавленные пустые строки о_О

(0) Расширения это только дополнительный инструмент.Перспективный.Но пока ещё достаточно неполноценный для массового перевода на разработку в расширениях.После определенного , достаточно успешного опыта их использования пришёл к выводу что буду их использовать , но без фанатизма.Иначе получается теряется эффективность , вместо упрощения получаем усложнение и замедление разработки и поддержки.

(66) Потому-что #Вставка … #КонецВставки

(66)Такая же проблема, бьешься как дурак каждый раз. Иногда получается. Иногда нет.

Точка. :)