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

(0) идеологически верным является разбивка на задачи.

(0) вот кто сказал, он и ответ должен знать.
А то получишь по шапке за инициативу.

(2) Он не знает. Ему франь рассказал, расширения это круто.

(0) // Даже внешние печатные формы запретили.

Угу. Я бы их на уровне БСП запретил. Методически.

(0) В одном случае правильно будет одно большое расширение. В другом - несколько небольших. В третьем - одно большое И несколько небольших. Главное - это правильно определить, какой именно у тебя случай. Тогда и на вопрос ветки получишь ответ.

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

(4) Так что, все уже. Внешние печатные формы померли? И что заместо них теперь?

одно большое - чсем будет отличаться от той же конфигурации?
потом хренячить расширения на расширения?

(7) никуда не померли

мы делаем несколько , 1 исправление/задача  1 расширение . Большое сложно тестировать.

(10) а как вы совместную работу тестируете?

(7) расширения! одни сплошные расширения

:-)

(0) >> все делать через расширение, конфу ни-ни.

Дебилизм.
Сегодня прям какое-то очередное обострение среди фетишистов - фанатов замочков на конфигурации.

>> внешние печатные формы запретили.

А вот это правильно. Начиная с БСП 2.5 внешние отчеты, обработки и печатные формы следует делать через расширения и БСП-шную подсистему ПодключаемыеОтчетыИОбработки.

>> одно большое расширение куда все запихать, или несколько небольших, логически разбивая на задачи?

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

Но повторюсь! Расширения - зло.
Правильно делать доработки внутри основной конфигурации.
Исключение - временные патчи (которые будут удалены как только исправление будет в основной конфе) и дополнительные подключаемые отчеты и обработки (то, что раньше называлось внешними отчетами и обработками). Всё остальное - внутри.

(12) Да ладно. ВПФ очень удобны.

(14) абсолютный мусор твои ВПФ.

В Расширении с ними крутиться намного легче. Намного меньше ошибок. Больше возможностей.

(15) Да бин, таким темпами, у меня полконфы в расширение уйдет.

правильно одно маленькое расширение..

(16) стильно, модно, молодежно :-)

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

сейчас уже бсп 3.1, но впф все еще на месте

Я как опытный хренакатель 20 расширений в базе уровня ERP могу сказать, что лучше не использовать расширения для крупных доработок.

(16) Не уйдет.

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

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

Мое мнение: расширение рекомендуется использовать только в качестве "патча" (исправление ошибок) и в небольших проектах (в которых не требуется хранить данные в объектах расширений).

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

Расширения - это не панацея, это не "таблетка от всех болезней". Это всего лишь инструмент со своей сферой применения.

(22) Так же думал, вот уважаемый Фрэнки говорит что все, надо работать по новому.

(25) Кислое с пресным не путай, а читай что он тебе говорит.

(20) >> сейчас уже бсп 3.1, но впф все еще на месте

Они и будут на месте.
Ради обратной совместимости они в ближайшее время никуда не денутся.
Но это не значит, что фигачить ВПФ нужно и дальше.

(26) Мне походу нужен переводчик. Чето я совсем запутался.

(28) он тебе лишь про это https://its.1c.ru/db/bsp301doc#content:53:1:issogl2_разработка_команд_печати_в_расширении_конфигурации

(23) https://its.1c.ru/db/bsp312doc#content:53:1:issogl2_разработка_команд_печати_в_расширении_конфигурации

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

А все остальное в конфу.

Правильно - без расширений.
Но если деваться некуда - я бы все пихал в одно.

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

(0) современная платформа еще сыра для работы с большим количеством расширений (от 3 и более), начинаются всяческие конфликты и затмения механик и алгоритмов одного объекта..

я бы пихал все в одно расширение..

(35) С чего такой вывод про сырость платформ? Есть глупость программиста, который, например, работает с одним документом, мало того, с одной его формой, но каждый раз делает новое расширение. Это ДА. Тогда точно будет то о чем говоришь.
Самое правильное, на мой взгляд, в (13). И... самая большая глупость, пихать все в одно расширение. Такое могут посоветовать только те кто никогда не работал с расширениями

(0) У меня более 30 расширений, они не пересекаются.Сгруппированы по задачам.Удобно .

(37) +Часто это что то типа патчей, исправляющих чудаковатость или недопонимание разработчика типовой.

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

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

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

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

Это я просто к тому, что пытаться навешивать ярлыки - это зло! - ну примитивно очень.

Так-то если дальше рассуждать, то окажется, что возможности расширения все-таки не только удобней ВПФ и внешних отчетов или обработок, но и реально расширяют/модифицируют функциональность от текущей конфигурации инфо-базы.

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

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