Дорабатывается типовая конфигурация (Документооборот в частности).

В первом варианте теоретический минус - один косяк, всё расширение отключено. Групповая разработка страдает, в ДО мало объектов.
При втором варианте - будут наслоения заимствованных форм и расширений событий. Поди разберись без EDT во всех цепочках.

Как, на ваш взгляд, правильно делать?

(0) Снимать с поддержки и пилить без расширений
Это же ДО, оно редко обновляется

Расширение есть смысл когда тиражный продукт

Или типовая конфа слишком часто обновляется но надо оперативно и легко обновлять
И пофиг что слетит доработанный функционал, главное чтобы типовой работал

Правильнее снять с поддержки и работать в основной конфигурации

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

(1)+ Причем сразу правила доработки придумать и строго их выполнять
Все доработки форм только кодом
Типовые ПФ не трогать, делать свои копии ПФ с префикс_ и заменять в коде вызовы типовых макетов на свои
И т.д.

П.3. Порождает чудовищ. ))

(5) пишется так: "Сон разума рождает чудовищ"

(0) Вариант 3 абсолютно точно нет
Непонятно, как и зачем делить общие вещи, относящиеся к нескольким функционалам
Непонятно, что делать, если доработка предполагает использование чего-то из другого расширения
Непонятно, как контролировать, какое из расширений содержит финальный вариант объекта и есть ли такое вообще
Короче, сплошные вопросы

И да, расширения — это не для групповой разработки
Групповая разработка так-то по-другому организовывается, ГИТы там всякие, ЕДТ

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

(4) >>делать свои копии ПФ с префикс_ и заменять в коде вызовы типовых макетов на свои
Убивать за такое
Как раз (5)
Через несколько релизов никто нихуя не сообразит, что это за говно, которое сто к одному первоначально родилось в недрах 1С, но сейчас на 1С не похоже, потому что куча отличий, которые практически все, сюрпрайз, мазефака!, тоже сто к одному, родились в недрах 1С
Особенно такое радует, когда какой-нибудь дебил скопирует типовую роль, поправит в ней пару мест и догадывайся потом, что именно он наменял, чтобы синхронизировать его переставшего после очередного обновления работать выродка с типовым оригиналом

(7) (5) по 3 тоже удивился, когда на собеседовании одна компания сказала, что так работает. А где сейчас работаю там пока идет по этому пути, не допускают на испытательном сроке до хранилища конфигураций.

(11) Я бы Вас вообще до прода не допускал.

(11) То есть ты удивился, что может быть несколько расширений?
Или что они дешево и сердито кустарно распараллелили разработку?
Или ты просто решил сейчас показать, что ты тоже умный, хотя показал лишь свою глупость, сказав по сути, что молоток — это плохо, потому что им можно голову проломить, забыв выяснить, как именно молоток применяется в конкретном случае?

(10) Это лучше чем типовое править в редакторе а не программно
Когда есть копия с префиксом и типовая заменится то концы можно найти

А если затерлись доработки типовым обновлением то все
И как сравнивать будешь когда формы/макеты поменялись???

(12) При групповой разработке до прода вообще допускают только одного, кто накатывает проверенные обновления
А то вот так сиди и молись, что среди стада студентов не найдется какого-нибудь ТС с кашей в голове, который накатит какое-нибудь невнятное непонятно что, которое стопорнет работу компании

(14) Расставляйте запятые

Некий гибрид: есть "основное расширение", в котором реализована бОльшая часть доработок. И, для решения узких отдельных задач, могут быть отдельные расширения. Например, собственные патчи.

(15) Я бы его не допускал до храна, которое идёт в прод. Пусть тренируется на кошках

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

(14) Говно это собачье, а не бэст практикс лучшее из лучшего
Ниже правила, соблюдение которых делает доработку на два порядка лучше, чем такое закапывание мины замедленного действия, которую, сука, когда-нибудь придется выкапывать:
1. Правь кодом все, что можно, включая изменение макета
2. Что невозможно править кодом, помечай префиксами, например, новая область в макете
3. Все изменения по возможности делай в конце (модуля, макета)
4. Минимизируй изменения, то есть не нужно копировать весь, блять, макет ТОРГ-12, если тебе нужно только вставить в ней где-то свою строчку, сделай или измени одну новую область
5. Все, что наменял не в коде, обязательно комментируй в модуле объекта
6. Если ты меняешь что-то, что ну никак никуда не вписать, а вот нужно тебе, аж кющать не можешь, то подумай, как тебе это задокументировать обновляющему так, чтобы он не наложил на тебя анафему потом

Общее правило: даже комментарий в модуле приложения о том, что ты изменил то-то и то-то в общем макете таком-то, лучше, чем блядская копия этого макета с неизвестной версии типового макета

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

(18) Так разработчиков и не допускают, все в своих ветках ГИТа :))
За мерж в мастер сразу расстрел, зачем стране имбецилы
Дали тебе добро мержить свою проверенную ветку в мастер — мержь, нет — какого вдруг хрена ты туда полез, урод?

(19) Я и говорю, каждую доработку в отдельное расширение — это сразу к стенке такого вредителя

(0) Скажу за свой опыт доработки ДО.Порядка десяти расширений.Это не проблема разработчику держать сведения по всем доработкам и грамотно их распределять по различным расширениям.Принцип SOLID в действии.
Плюсы - простое обновление и миграция на ДО3.Косметическая правка расширений для ДО 3.
Однако если держать стадо разработчиков,то нужен гуру,иначе наколбасят,как пишут в этой ветке.

(20)
И затри свои изменения типовым релизом, да?
Думаешь реально кто-то будет сверять (и как???) макеты?

(25)+ Так что или программно править макет
Или копировать его с префиксом, не трогая типовой
Тогда после обновления типовой - можно будет найти концы и восстановить, причем легко

(25) 1. Да лучше пусть твое говнотворчество затрут, раз ты не удосужился его толком задокументировать
2. Думаю, что да, будут сверять, если только их делала не какая-то скотина, которой посрать, сколько времени обновляющему нужно на расследование того, что она там наменяла
3. Ты не поверишь, но макеты сто лет в обед сверяются
Профессионал, твою мать, про сравнение макетов не в курсе

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

(27) >3. Ты не поверишь, но макеты сто лет в обед сверяются
Нюню
Какой смысл сверять старый типовой исправленный макет с совершенно новым типовым?
Который не на основе прежнего а с нуля разрабом типовой сделан
Что ты там на сверяешь?

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

(29) Все веселее и веселее
Только что ты не знал, что макеты можно сравнивать
И тут ты решил пробить днище и предложил зачем-то сравнивать старый типовой исправленный макет с совершенно новым типовым
Зачем? Некогда объяснять, суй помидоры в жопу!
А, я понял, гораздо проще же, как правило, вручную перехуярить охулиард типовых изменений макета, чем парочку своих говноизменений
Нельзя потом сравнить, верно ли ты и все ли перенес? Да посрать, давай быстрее, время деньги, ага

пилить в основной конфе с префиксами (объектов, реквизитов, процедур и др.) + комментарии в коде

(30) Не отмазывайся уже
Формы тоже можно сравнивать и объединять ты этого не знал?

Но почему то формы предлагаешь только программно кодом ))

(32) Рукалицо
Я предлагаю переносить кодом все, что можно
И макеты тоже, ага
В отличие от тебя

(33) Прочитай внимательно (26)
там

(34)+ а вот править (в редакторе) типовой макет "местами" даже помечая их областями с префиксом - это изврат

(34) Да не стесняйся, прочитай первоисточник (4)

(35) Не пытайся натянуть сову на глобус, прочитай (20) полностью

(36) прочитай уже сам (4)

и еще скажи что ПФ это не Печатная Форма

(37)
а теперь глянь сюда
Комментарии ("номера задач") для объектов метаданных при разработке

(38)+ не трогать типовую ПФ!!!
кодом вместо типовой вызывать свою (скопированную типовую или совсем новую)
или менять типовую программно

никаких ручных изменений типовых ПФ в конфигураторе

(38) Да блять
"Типовые ПФ не трогать, делать свои копии ПФ"
Да, именно, ни полслова про изменений типовых ПФ кодов, только хардкор только копирование целиком и изменение скопированного

(41) в (40) пояснил уже

(39) Нахуя? Куда еще мне нужно посмотреть и зачем?

(43) модуля объекта может не быть

(44)+ не знал?

(42) Ты в (40) пояснил, что да, ты долбоеб и гордишься этим
Я понял, твой выбор
Зачем ты мне это повторяешь, с какой целью?

(44) Может
И если бы ты умел читать, то прочитал бы, что я написал про этот случай
Но чукча не читатель по ходу

(46) плиз не переходи на личности
сам ты небинарный

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


(32) Некоторые сравнения форм и макетов которые я видел, вызывали очень острые ощущения ниже спины. Код по возможности лучше.

А например скопировать внтури макета область и назвать её с префиксом? И есть что сравнивать и есть с чем сравнивать и понятно по коду вызывается заполнение области "префикс_Подвал"

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

(49) угу
поэтому лучше не трогать типовые формы как объектов так и печатные (макеты)
только программно их
или копии и подменять

(50) лично я предлагаю более строгое ограничение и более надежное
и оно ничуть не сложней а даже проще при обновлениях

включи мозг и попробуй

(52)+ ты пишешь что можно ПФ (макеты) править в редакторе
я же говорю - низзя!
только программно или свой макет (копия типового с доработками или новый) и кодом подменять (вызывать свой)

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

Все верно, я ничего не перепутал?

(53) А почему нет? Типовой макет на текущий релиз лежит в конфе поставщика. Если форма заменяется полностью, принято решение ПФ не нужна в базовом виде. При обновлении ты переключаешься между сравнениями и понимаешь например: базовая форма изменена размерами колонок, не трогаем свою. Если другое, уже нужно подключать мозг и думать.

(53) Я не говорю, что нужно, но да, можно, что такого-то?
Ты по сути делаешь то же самое, как будто переживаешь, что типового макета нет в конфигурации поставщика, нужно его еще и в основной конфигурации сохранить
Посрать, что это резко усложняет жизнь пользователю, зато типовой макет будет по прежнему типовым, пусть даже не исходным для измененнного тобой, а уже сто раз измененным фирмой 1С, пусть нихрена не используемым и нахрен никому не нужным, пусть доработанный макет с ним нихрена уже не сравнишь и не найдешь концов, но зато типовым, да

(54) указать с какого никто не мешает
как и сравнением найти с какого
и это надежней и проще, чем искать что пропало после типового

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

(55) Вот, человек верно говорит, типовой макет есть в конфигурации поставщика, нахрен он нм нужен еще где-то?
Хочешь зачем-то хрен знает зачем зафиксировать оригинальный макет, с которого ты лепил свой — скопируй уж тогда его с типового и назови ИмяМакета_Типовой, он хоть обновляться 1С автоматически не будет
Хотя, еще раз, даже такая хрень никому не нужна, просто тупо меняется типовой и все, кодом или сам макет, не важно, это уже детали

(57) Чтобы сравнить два разных макета, сравнить с конфигурацией поставщика не получится, придется сохранять оба макета в файл, сравнивать файлы, смотреть отличия
Если при этом таких макетов много, нужно будет для каждой пары все это повторить
И вот тут вопрос, нахрена?
Ты любишь стоя и в гамаке?

(58) Примерно то же самое говорят ебанутые, которые, например, вместо доработки типового поступления денежных средств перепиздячивают всю конфу на новый документ, который копия типового, но в нем добавлен реквизит "Курс доллара в день оформления документа"
Зато типовой, блять, остается девственным как монашка, да

(61) может просто некто не разобрался почему сделали копию типового документа?
и да
слить не проблема
разделить сложно

Никто из таких гениев не может ответить на простой вопрос "Зачем тебе нужен неизменный объект?"
У всех у них мутные сомнительные ответы из серии "Так проще", "Так надежнее" или "Так правильнее"

Зачем?

(62) В смысле не разобрался?
Потому что добавили реквизит "Курс доллара в день оформления документа"
Не ломать же из-за этого типовой документ
НАМ НУЖЕН ТИПОВОЙ ДОКУМЕНТ НЕТРОНУТЫМ!
— Зачем?
— Так проще
— Зачем?
— Так надежнее
— Зачем?
— Так правильнее
— Зачем?
— Да не знаю я зачем, просто хочу стоя и в гамаке!

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

(65) Обычно такое говно проживает долгую и счастливую жизнь и умирает своей смертью в окружении аналитиков, программистов и ЛПРов, встревоженно ждущих, какого говна им привезет смерть этого чудовища

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

Как видим в процессе уменьшили сложность типовых обновлений
Если общий (типовой) документ уже не нужен - кто мешает их перекинуть на допиленные и даже движения перепривязать задним числом

(67) Неизвестность мешает
Вдруг после этого бетонная плита упадет на феррари директора?

(67) Еще раз это типовой функционал, который когда-то сам разработчик разделил. Не переименовал объекты и теперь в конфигурации  

1:
Наименование: Операция 1
Синоним: Операция1, операция2...
2:
Наименование: ТолькоОперация1
3:
Наименование: ТолькоОперация2

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

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

На инфостарте когда-то была статья хорошая про жизнь с зоопарком расширений. Сейчас не смог быстро найти.

Автор задавалась примерно таким же вопросом.

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

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

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