День добрый. вопрос собственное в теме. Создал расширение, а как их правильно именовать не знаю.
Расш1_ как то слишком информативно, может есть какие рекомендации по именованию?

Барсик_ ...адаптация
Мухтар_ ...исправленя

что типа
НазваниеОрганизации_Адаптация
НазваниеОрганизации_Исправления
?

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

СправочникСотрудники
ДокументРеализацияТоваров
ПроведениеПоПартиям

Монстрорасширения не создаю. Лучше сделать несколько расширений, каждое отвечающее за свой участочек, чем одно большое

(3) А вот и нет

(2) угу, будет в конфе 25 расширений, и ты предлагаешь каждое открыть и просмотреть, чего же в нём понаправили?

(4) что нет?

мнения разошлись :)

а количество расширений не влияет на скорость работы?

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

(3) лучше сделать одно расширение и повесить его на хранилище+гита чем следить когда что и кем поменялось в 25 расширениях.
все эти "если в другом расширении сломается, зато мой кусочек будет работать" от лукавого. исключения - расширения от сторонних производителей.

КомпанияКратко_КраткоеНазначение, например
ККК_Аренда, Азот_ЛогистикаПродаж

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

(3) Если говорить в целом, то подход - огромная ошибка в перспективе.
Делайте одно монстрорасширение.

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

Расширение1
Расширение2
:))))

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

(16) а зачем перекидываете? какая необходимость в расщирении?

Хотя вот тут уже обсосано Расширения: одно vs много

(14) ну хотя бы по подсистемам.

доработок мало, есть желание поставить на замок.
основа это перекинуть синхронизацию данных.

(13) например?

(12) обновления, как правило, делают на копиях с укрощением монтсров-расширений.
потом на проде в полпинка и без паники, нэ - не так, вы укрощаете тигров не в клетках, а у себя на кухне?

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

(0) Можно разбить по:
1. Проектам.
2. Видам и месту доработок.

Примеры по проектам:
1. Интеграция с ОФД.

Примеры по второму пункту:
1. Исправление ошибок в релизе (БП)
2. Доработки локальной базы (БП)