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

практика показывает что лучше так

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

(1) как находите в каком расширении уже расширен какой-то объект?

И так плохо и так плохо, особенно когда нужно внести исправления. Сидишь и щелкаешь в поисках нужного расширения

(4) Помогает документирование

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

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

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

Правильного пункта в голосвалке, как обычно, нет...

п. 4 кг/ам

up

пилю все в одном. чтобы не отвалилось есть тестовые базы

Доработок огромное количество, ничего не ломалось.

(0) Разделяй и властвуй.Принцип Unix.

(0) Самый правильный ответ в (8)
Самый вредный совет в (10) и (11). Рано или поздно ребята влетят с единственным расширением.

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

универсально правильного ответа нет ни на один вопрос процесса разработки ПО

(8) п3 вполне сойдет. если перегрузить слово блоки на метаданные и подсистемы.

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

Какие минусы у первого пункта? Ну, помимо мифического отваления одного расширения

(18) Как минимум один - это расширение )

(18) если отваливания нет совсем, то и смысла выносить доработки в расширения тоже нет совсем

(18) > Какие минусы у первого пункта?

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

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

Серебряной пули, ИМХО, тут нет. Каждый раз решение принимать следует исходя из конкретной ситуации и соображений здравой логики и разумности. Иметь более десятка расширений вряд ли можно считать хорошей практикой. Даже если они никак не пересекаются.

+ к (21) Извиняюсь. Не так понял вопрос из (18). Думал, что речь идёт о пункте "Под каждую задачу".

(18) Чем больше изменений в одном расширении тем сложнее со временем бывает разобраться - а что конкретно меняли и для чего (в рамках какой задачи). Особенно, когда ещё и поставщик меняет расширяемый(ые) объект(ы) и возникает необходимость сделанные ранее в расширении доработки модифицировать.

Без нормального механизма сравнения расширяемой конфигурации с её расширениями (желательно одновременно с несколькими) механизм этот остаётся ущербным и во многом неудобным.

С хранилищем расширения для документации и случаев отката когда "все отвалится".

4. Зачем вообще эти расширения?

(23) "Без нормального механизма сравнения расширяемой конфигурации с её расширениями" // Хорошо бы если б можно было сравнивать конфигурацию расширения с основной конфигурацией _на момент заимствования_

Делаем как в (8)

4. кг/ам

А еще дайте "подсистему" для всех расширений.
Чтобы я в вел подсистему "правка косяков" и отмечал бы в нужных мне расширениях что этот кусок кода относиться к этой подсистеме.
И чтобы щелкнул пальцем и я мог бы увидеть все куски кода из всех расширений относящихся к этой подсистеме

+ одно аварийные расширение на случай локального

(25) +1

(31) у меня например внесены изменения в формировании префикса. Либо каждый раз из ОМ выковыривать эту процедуру либо один раз написал расширение и забыл.
Или к примеру отключить контроль ГТД

Опять таки прикольный вариант с подменой в расширении окна "Информация при запуске" http://catalog.mista.ru/public/333876/

(25) Если вы не знаете зачем они, то вам расширения не нужны. Всё просто.

Удивляет количество голосующих за одно расширение на все изменения. Видимо еще ни разу не нарывались на отказ расширения. Проголосую за вариант два, хотя более прав (8)

(35) в чем отличие откатить на прошлую версию одно расширение из хранилища или обновить отдельно сломавшийся кусок? в мифической "части пользователей которые продолжают работать с частью модулей расширений без ошибок?"
в любом случае для исправления косячного кода нужно будет подгружать(динамически) расширение.
да, так подгрузок будет на одну меньше. но это рассуждения из серии постелить соломку.
зато щас если 5 расширений+ПереопределяемыйЧтобЕгоМодуль=поди найди откуда данные и их обработчики на форме взялись.

"зато щас если 5 расширений+ПереопределяемыйЧтобЕгоМодуль=поди найди откуда данные и их обработчики на форме взялись." - именно!
Вот интересно, сколько расширений одновременно используют сами разработчики 1С? Мало нам безумной вложенности процедур, теперь еще на всё это наложим расширения, чтобы итоговый код превратить в полную загадку.

(37) > сколько расширений одновременно используют сами разработчики 1С?

Им то оно зачем? Они авторы расширяемых конфигураций, а не расширений.

4. Фигач сразу в конфу

(36) При чем здесь откат на предыдущую версию? Одно это показывает, что вы не сталкивались с отказами расширений. У вас 10 расширений по задачам. Разработчик конфигурации в очередном обновлении заменил ТипНоменклатуры на КатегорияНоменклатуры (реальный случай с одним из моих расширений). Одно расширение отвалилось. Но остальные работают. В одном расширении рухнут ВСЕ изменения до правки казалось бы мелочи, но на что надо и время и умение (а не факт что это расширение писали вы и вам еще надо время разобраться) В итоге программа практически становится неработоспособной  в привычном и нужном виде. Никакой откат из бэкапа не поможет

Лучше вообще без расширений, если обновляться приходится.

(41) Наоборот!Смысл именно в том чтобы не делать фигачвконфу (39).

(42) +Вернее «фигачпрямовконфу»(С).Эта технология скоро канет в лету,когда 1с наконец то выпустит типовые решения без поддержки совместимости.Они до сих пор, несмотря на наличие 8.3.13 держат Ут11 в режиме совместимости 8.3.10(((.А это довольно сильно сдерживает применение расширений, оставляя им роль патчей, которые и сама 1с готовиться выпускать.Но даже в таком виде расширения себя Отлично зарекомендовали.

(40) ну тут как бы надо хотя бы проверять возможность применения расширений

(42) смысл в том, что сразу видны конфликты / дважды изменённые объекты и не надо шариться по расширениям по всем процедурам вместо

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

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

(44) "ну тут как бы надо хотя бы проверять возможность применения расширений"
Да работало это расширение почти полтора года, но очередное обновление конфы внесло критические изменения. Тут проверяй не проверяй.
"и не надо шариться по расширениям по всем процедурам вместо" Да. Пока это является какой-то проблемой. Но немного облегчить ее можно соблюдая некоторые правила
Во-первых присваивайте понятные, отвечающие действительности, имена расширений. Не абстрактное Расширение_1, а, например, АвтоЗаполнениеЗаказа
Во-вторых Не ленитесь чистить созданное расширение от всего лишнего в заимствовании. Например, заимствованная форма тянет всё по типам реквизитам, а реально зачастую надо что-то одно единственное, остальное - удалить из расширения. В будущем - большое подспорье в поиске и правке расширения
В-третьих Общая рекомендация всех учебных материалов по расширениям: Вместо - только в самых крайних случаях, когда действительно больше ничего уже нельзя сделать. И практика показывает, что в 90% случаях Вместо вполне можно обойти и заменить на Перед и/или После.

(46) Так я же признаю это в (45).Да ,сложно,пока нет удобного инструмент для сравнения.Но допилят же наверное.А сейчас только осмысленное применение и документирование расширений может помочь.

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

Не очень понимаю проблему одного расширения. Какая разница отвалится у вас весь функционал расширений или 1/10. Исправлять нужно в любом случае. Единственные случаи, которые я встречал, что расширение переставало работать, это после обновления. Но я думаю, в крупных фирмах никто не обновляет в середине рабочего дня. А вечером, когда уже никого нет, вам никто не мешает нажать кнопку "проверить возможность применения всех расширений". И какая в данном случае разница, одно расширение у вас накроется с 10 функционалами, или одно из 10ти с одним функционалом? Исправлять в любом случае придется.

(43) ты не поверишь но БП тоже в режиме совместимости. В режиме совместимости в 8.3.12. А значит все плюшки расширений 8.3.13 и выше будут еще пару лет недоступны в типовых, пока 1с не передет на 8.3.14

(49) В (43) я упоминал патчи, на мой взгляд,это средство оперативного устроения глупых ошибок в конфигурации без выпуска полноценного обновления в экстренном порядке.Патч поставить значительно проще.

(51) Да,БП и ЗУП они осилили) Но меня больше интересует УТ.А совместимость с 8.3.11 уже была бы прорывом.А что там в релизах 12,13 с расширениями добавили революционного?

(53) Самое вкусное

регистры накопления;
регистры бухгалтерии, планы видов счетов и планы видов характеристик;
регистры расчета и планы видов расчета.

+ Новые возможности расширения планов обмена

(50) Проблема в том, что проверка возможности применимости расширений не выдаст Вам всех ошибок. Точно так же как синтаксический контроль самой конфы не гарантирует, что ваш код рабочий.
Если разработчик поменял имя реквизита, к которому вы обращаетесь в вашем расширении, то контроль применимости вам об этом может и не расскажет. Узнаете вы о косяке уже от пользователя.

То есть в идеале после каждого обновления мало проверить применимость. Надо тестировать каждую доработку, сделанную в  каждом из расширений.

(53) + фишки из 8.3.14
https://wonderland.v8.1c.ru/blog/razvitie-mekhanizma-rasshireniy-konfiguratsii-14/

(55) Но тогда каждое расширение может накрыться с тем же успехом, что и одно. Но одно дело, когда у вас отваливается расширение, а другое, оно работает, но работает неправильно. И опять же, в случае одного расширения, отследить проще. Если разработчик поменял имя реквизита, а я обращаюсь к этому реквизиту, то расширение заимствует этот реквизит. А значит, после обновления, у меня будет ошибка, которая сообщит, что имя заимствованного реквизита не совпадает, или не найдено, не помню точно. Другое дело, что если разработчик поменял метод, к которому я обращаюсь из расширения, и изменил логику его работы, тогда да, это уже проблема. Но тут неважно одно расширение или несколько, проблемы и так и так будут. Речь же идет о том, что если отвалится расширение, а не о том, что правильность логики его работы будет нарушена. Во втором случае, неважно 1 или 10 расширений, они всё равно будут работать.

(45) что хуже, медленно, но все моменты - видны сразу
или быстро, но вместо обновления - иллюзия, что всё работает как надо (перекрытие "вместо" - это самый простой вариант потери обновления)?

А кто-нибудь в курсе как будут храниться реквизиты добавленные в расширение? Если я добавил пару новых справочников в расширение, а потом отвалилось расширение, удалил, перенес, обновил? Добавил новое? Как долго призраки справочников будут жить в базе, после того, как я удалю расширение? А если отключу?

Извините, в (56) есть ответ на мой вопрос.

(55) "Если разработчик поменял имя реквизита, к которому вы обращаетесь в вашем расширении, то контроль применимости вам об этом может и не расскажет" // Если это реквизит на уровне метаданных, и он используется в коде, то он в расширении должен быть заимствован с контролем изменения

ровно столько сколько и обычный реквизит. Удалил реквизит/расширение удалилось значение из базы. Добавил новое - получи пустое значение

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

(59)
https://wonderland.v8.1c.ru/blog/rasshirenie-dannykh/

(61) Имя-то реквизита в базе изменится и в расширении тоже, а вот в коде расширения - хренушки, только руками

(65) Но с точно такой же проблемой можно столкнуться и без расширений. Это никак не влияет на выбор одно или несколько расширений использовать.

(65) Тогда такое расширение не пройдет синтаксический контроль. Ну, если обращение к реквизиту через точку, а не через квадратные скобки, например.

(67) В тексте запроса пройдёт.

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

(68) (69) Ну, видимо вот это вот все - плата за модульность.
Считаете, что будет хорошо, если перед обновлением конфы БД будет принудительно запускаться проверка конфигурации всех подключенных расширений?

(32) Зачем каждый раз выковыривать? Если процедура не менялась - просто галку не ставить. А если менялась - то "забыть" все равно не получится.

(37) Народ наследование просил.

(42) Пока что оно работает так, что сразу в конфу удобнее получается при обновлении.

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

(72) Просто ребятки из 1С, сделав для своего фреша эти расширения, пытаются "продать" их и тем, кому от этого ни жарко, ни холодно )

(0) Вот пример осмысленного применения расширений из соседней темы засветился.Там ошибка и перечень расширений.
http://ipic.su/img/img7/fs/Bezymyannyj.1538646040.jpg
Мне нравиться.Именно под задачу сделано.

(24) "хранилище расширения", можно подробней?

(75) что именно подробнее? обновляетесь до 8.3.12, делаете отдельное хранилище для расширения и радуетесь.

(76) но оно все равно отдельное от конфы?

(77) Да, можно считать что это отдельная конфа со своим хранилищем поверх вашей.

Делаю по блокам учета, н-р "Производство", "Розница", "Покупки", "Продажи" и т.д., что позволяет избегать дублирования кода.
В расширении каждая отдельная задача полностью реализована в отдельной обработке.
Объекты основной конфигурации не заимствую - вся работа построена на программных
подписках на события.
Выложил видео с примером таких подписок:
https://www.youtube.com/watch?v=DjSR8T19PiA