Добрый день!

Не так давно сделал расширение, назовем его Расширение1. В нем есть несколько общих модулей.

Затем начал делать второе расширение - Расширение2. Функционально это расширение не имеет ничего общего с первым расширением.
Но многие методы из общих модулей Расширения1 можно было бы использовать и в Расширении2.

Дублировать код не хочется. Снимать с поддержки типовую конфигурацию тоже не хочется.
Что можно сделать?
Куда можно вынести общие модули (или отдельные методы) из Расширения1, чтобы их можно было использовать в Расширении2?

(0) В расширение 3

(1) А как потом использовать код из Расширения3 в других расширениях (в Расширении1 и в Расширении2)?
Вроде как они не "видят" друг друга.

(2) Слово "вроде" тут меня смущает.

(3) "Вроде" обозначает, что я попробовал - и сходу не получилось.

Но, Ваше смущение навело меня на размышления.
И я попробовал еще раз.
И все получилось! Спасибо.

(0) Общие модули (или отдельные методы), как и все остальное, из Расширения2 можно вынести в Расширение1, а Расширение2 можно вынести на помойку

+(5) Особенно с учетом квалификации ТС, написавшего (2)

Так не работает?
ОМ = Вычислить("ОМ1");
ОМ.СделатьХорошо();

(7) Даже так работает
ОМ1.СделатьХорошо();

(8) Вроде при компиляции должно упасть.

(9) Оно ругнется, но работать будет

(8),(10) Подтверждаю: работает. И не ругается.

Недостаток только в том, что "Перейти к определению" не срабатывает.

(9) При какой, нахрен, компиляции?
1С ничего не компилирует, 1С интерпретирует на лету, перевод в байт-код не считается

(10) Ругнется только синтакс-контроль, на него начхать

(11) Удивительно, да?

(13) Синтакс-контроль тоже не ругается.

(5) >> Общие модули (или отдельные методы), как и все остальное, из Расширения2 можно вынести в Расширение1, а Расширение2 можно вынести на помойку.

Нет, это плохой подход. Так Расширение1 неимоверно распухнет.
Удобнее вести разработку нескольких расширений, у каждого из которых свой функционал.
Причем каждое расширение связано со своим Хранилищем.

(6) >> Особенно с учетом квалификации ТС

Квалификацию наработаем.
Но чтобы наработать квалификацию - надо делать "правильно", и не искать обходных путей.

(0) делай одно расширение, если они будут работать вместе и все равно зависимость появляется

или дублируй код, если они должны работать по отдельности

Кстати, сразу еще вопрос про использование расширениями друг друга...

Можно ли команду из Расширения2 разместить в подсистеме (в разделе) Расширения1?

(15) ты пробовал? каждый раз при входе 20 раз подключаешься к 20ти расширениям и 20 раз получаешь изменения из хранилища?

(17) 🤦‍♂️

(16) >> или дублируй код, если они должны работать по отдельности

Да, они должны работать по отдельности.
Но дублировать код плохо.
Лучше уж тогда сделать типа "Расширение_Основное", которое содержит общий код, и "Расширение1" + "Расширение2", у которых разный функционал, и которые используют общие модули Расширения_Основного.

>> ... все равно зависимость появляется

Зависимость дело неизбежное. Любая программа на любом языке состоит из разных модулей, которые зависят друг от друга. Будь это C# или 1С.
Главное правильно разделить эти зависимости.
Должны соблюдаться SRP, LSP, ...

(17) Пиздец

Каждый учится на своих ошибках. Нафиг учиться на чужих. ))

(22) Не, по ходу ТС ничему не учится
Упоротый говнокодер детектед

"Лучше уж тогда сделать типа "Расширение_Основное", которое содержит общий код, и "Расширение1" + "Расширение2", у которых разный функционал, и которые используют общие модули Расширения_Основного."
А потом кому-то для 25-ого объекта в 130-ом расширении потребовалось чуток поправить процедурку, которую зачем-то вызывают из раширения_основного...

Почему то вспоминается тема, где автор команду в интерфейсе видит, а какое из многочисленных расширений её добавляет уже не помнит. И найти не может :-)

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

Про ошибки по вопросу использования одним расширением другого расширения тут пока еще никто не упоминал.
Если в этом вопросе есть какие-то "подводные" камни - пожалуйста, объясните.

(24),(25) >> А потом кому-то для 25-ого объекта в 130-ом расширении потребовалось чуток поправить процедурку ...
>> ... автор команду в интерфейсе видит, а какое из многочисленных расширений её добавляет уже не помнит ...

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

(27) если у вас все спроектировано идеально, то в чем вопрос?

(23) >> Не, по ходу ТС ничему не учится
>> Упоротый говнокодер детектед

Аргументируй.
Без аргументов - это болтовня и желание самоутвердиться.
Ты не мог сделать выводов о моем коде, так как вопросов о коде не было.
С таким же успехом я могу в твою сторону написать тоже самое.

(28) >> если у вас все спроектировано идеально, то в чем вопрос?

Оно еще не спроектировано, пока еще находится в процессе проектирования.

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

(30) Ну не видят расширения друг друга.И отказ от синтакс контроля не приветствую.Не нужно так делать.Удобства разработчика выше ценятся, чем возможность налепить "на авось".
Если у вас появились "золотые" методы,которые вы используете в разных расширениях,делайте их отдельным модулем расширения, без заимстврвания кода основной конфигурации, разными версиями.А если "золотые" методы заимствуют типовой код - то налицо ошибка в проектировании расширения1 и расширения2.

(31) >> Ну не видят расширения друг друга.

Правильней сказать, что расширения видят друг друга, но ограниченно (не "полноценно").

(31) >> И отказ от синтакс контроля не приветствую.

Согласен. Есть над чем подумать.

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

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

такого насмотрелся :) не ругайте погромистов - они погромируют как умеют

ТС-у для расширения кругозора навскидку:

https://infostart.ru/1c/articles/1960294/
https://infostart.ru/1c/articles/1211271/

вот еще конвертатор для удобства
https://github.com/best-tech/cfe2cf

(32) представьте себе, что у вас есть два расширения, первое с типом адаптация, а второе - дополнение. Второе будет видеть методы первого, а первое второго нет.
А если оба с типом адаптация, то первое то будет видеть метод первого, то нет и наоборот.
Поэтому идея выносить что-то в "общее расширение" крайне сомнительная.

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

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

(36) коротенько:

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

вишенка на торте - &Вместо

закоментированы простыни запросов из типового кода и следом новый код запроса творчески доработанный и с костылями и еще вдобавок причесанный (как потом это дерьмо поддерживать?)

два дня протратил в основном на сравнение текстов запросов и расстановку комментариев

//{неизвестный го.внокодер начало
...
//неизвестный го.внокодер кончало}

ну и естественно весь шлак ненужный вынес на помойку :) перенес то, что действительно используется

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

(38)Есть обычный для 1с запрос, примерно на 1500 строк. Его нужно поправить. И как Вы правите? просто грубо ножом в тексте? Изменился типовой запрос, Вы глазами ищете отличия и пропускаете. А "Вставить" и "Удалить" хотя бы ловит эту ситуацию. Лично я пока не увидел причины по которой Вы переносите все обратно.
"Вместо" бывают почти равны исходному тексту, но это 1С делает такие коды размером с гектар. "Вместо" с "ПродолжитьВызов" бывает очень кстати. Главный плюс расширения - это обновление. Часто оно значительно проще. Но со своими тараканами

(40) причина банальная - поддержка

плюс расширения - это костылик вставить временный (патчи в терминологии 1С)

на этом плюсы заканчиваются

(36)не факт, что прежний говнокодер. Возможно его подход не совпал с Вашим. Следующий назовет Вас говнокодером. Но про расширения так почти ничего и нет, в основном про говнокодера

Причина похоже религиозная )

(40) да о чем спорить? я вас не агитирую. Расширяйте на здоровье

— Я тебе не верю!
— А я тебя ни}{уя и не убеждаю… Это факт… ©Большой Куш(спиздили)

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



в ж.пу эти концепции

(44)я и не спорю. Просто всегда настораживает категоричность в суждениях

(44)

>> он носит, по большей части, дополняющий характер

А потом 1С хер@к и удаляет функции, модули рефакторит
И машет рукой расширениям

P.S.
Обновил ЗУП

РегистрСведений.НастройкиТранспортаОбмена

превратился в

Справочник.НастройкиТранспортаСообщенийОбмена

Зачем? Что плохого было в регистре?
Чем справочник кошернее ?

(40)


не нужно ничего глазами искать и пропускать

внешние программулины kdiff/p4merge сами всю работу делают, нужно только конфликты глянуть и принять решение по каждому

(37) просто спроектировано не очень 🤣 а так было бы супер

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

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

Если это действительно так, то это печально.
Я когда в (11) писал, что работает, я проверял на двух расширениях, оба имеют назначение "Дополнение".

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

Другого варианта нету: либо четкая документация и разумное проектирование, либо надо знать все "хитрости" наизусть.
Либо долго сидеть в отладчике, чтобы узнать эти "хитрости", если код незнакомый.

Требуют же некоторые работодатели знания БСП.
А какая разница - знать БСП или знать конкретное расширение\модуль, которые используются в конфигурации?

(43) причина скорее всего в здравом смысле

почитайте хотя бы еще раз до просветления (37) 28* расширений и расширение расширением погоняет и про своих тараканов в (40)

(26) Более квалифицированных коллег ты посылаешь нафиг с их мнением
Так что не нужно тут ля ля

(29) Тебе уже аргументировали
Куча связанных задач в разных расширениях — это говнокод
Потому что общие алгоритмы, общие объекты и вообще каша, кто там что где менял и что в результате всего этого вермута должно быть
Но ты же у нас самый умный, у тебя свое мнение, ну вот и развлекайся

(52)здравый смысл - это так, как делаете Вы. Все остальное - нездравый и говнокодерство. Что тут обсуждать, кроме деклараций. Ну не любите расширения - не любите. Я тоже не люблю. Но не отвергаю. Вот и вся разница.

(55) не люблю бестолковой работой заниматься

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

ну и патчи типовые от 1С, которые они иногда прям очень много выкладывают

патчи эти протухают (удаляются), когда версия изменяется у типовой (но появляются новые)

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

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

(46) а релизов через 20 снова сделают регистром сведений...

Расширение 1С – возможность доработки типовой конфигурации с сохранением типовой поддержки

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

ну конечно, без расширений никуда, когда абоненты и прочие фреши со смузи



то время как остальные абоненты хотят работать -я бы сказал "вынуждены", а не хотят :)

(54) >> Тебе уже аргументировали

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

>> Куча связанных задач в разных расширениях — это говнокод

А где есть куча связанных задач в разных расширениях? У меня? С чего ты это взял?
Я несколько раз написал - функциональность (то есть решаемые задачи) расширений разная.

То что эти расширения должны вызывать некие общие методы - это не признак говнокода. Допустим, во всех расширениях вызывается метод "СтрЗаменить(...)" - это что сразу все расширения стали говнокодом?

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

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

Но какое это отношение имеет к говнокоду?
Это вообще никаким боком к коду не относится.

>> Более квалифицированных коллег ты посылаешь нафиг с их мнением

Это кого же я послал?
Наоборот - я всех всегда внимательно слушаю. А иначе как можно выбрать какой-то вариант? Надо выслушать несколько мнений, обдумать, попробовать.

(40) >> Главный плюс расширения - это обновление.

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

И это только верхушечка айсберга.

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

Конечно похожие косяки могут быть и при доработке в самой конфигурации. Однако в случае доработок внутри конфы при трёхстороннем сравнении во время обычного обновления до 90% таких финтов можно увидеть глазами. В случае расширения такого не увидишь никогда.

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

Расширения - это не панацея.
Это инструмент, которым надо уметь пользоваться. Пользоваться очень аккуратно и осторожно, помня о его довольно значительных ограничениях.

По сути PLUT прав в (41): "плюс расширения - это костылик вставить временный (патчи в терминологии 1С). На этом плюсы заканчиваются".
Подписываюсь под каждым словом.

Единственное что можно добавить к этому это в случаях использования БСП:
- Подсистема подключаемых команд (печати, заполнения и т.п.)
- Подсистема дополнительных отчетов, обработок и печатных форм (то что раньше делалось через внешние отчеты и обработки).
Тут тоже предпочтительнее расширения, чем вмешательство в конфу или использование устаревших внешних отчетов и обработок.

(60) ЧТД

(55) а вы жалуетесь или хвастаетесь :)
а мы покупаем или продаём?

погромисту из франча расширение удобно, т.к. ему нужно вставить свой код согласно задаче/ТЗ и "нате вам, тестируйте". чтобы его в хренилище пустили - это ж надо NDA, учетку в AD, учетку в хренилище... ну или тестовый контур отдельный разворачивать без подключения к хренилищу...

погромисту "в штате" - расширение не удобно, поэтому все сторонние доработки из расширений переношу в пофигурацию

(60)


Начнем с того, что если эта функция есть, то ее вообще глупо в расширение тянуть

(61)>Создаёт новый программный интерфейс. И при этом оставляет часть старого. Типа для совместимости.
Если в названии области написано, что это программный интерфейс, другого интерфейса для этой функциональности не будет. В этом вся суть интерфейсов. Ты можешь опираться на то, что он не изменится.

>Однако в случае доработок внутри конфы при трёхстороннем сравнении во время обычного обновления до 90% таких финтов можно увидеть глазами

Можно увидеть. А можно и не увидеть. 90% это цифра с потолка, на самом деле 50% - или увидишь или нет. Как повезет. Рассчитывать я бы на это не стал. К примеру есть метод1 который вызывает метод2(который ты изменил) который вызывает метод3 который реализует нужный тебе функционал. Вендор изменит метод1. Ты с чистой совестью при обновлении перенесешь изменения в метод2. Но он перестанет вызываться и метод1 будет вызывать метод4. Сравнение не покажет ничего(ты же не изменял метод1).  Расширения не панацея. Изменять конфигурацию не панацея. Ничто не панацея, только сама панацея - панацея. Перед установкой не поленись уж, прочти патчноут. Что там ставишь то и не затрагивает ли это доработанный функционал. А если затрагивает протестируй после обновления как работают твои доработки.

>Единственное что можно добавить к этому это в случаях использования БСП
В случае с БСП там почти на каждый чих есть переопределяемые модули. В которые можно писать. что угодно - вендор туда писать не будет точно.

(46)>Обновил ЗУП РегистрСведений.НастройкиТранспортаОбмена превратился в Справочник.НастройкиТранспортаСообщенийОбмена

Ну скорее всего непосредственно ЗУП здесь наверное даже и не при чем. Скорее всего, это обновилось БСП. Оно отвечает за обмены данными. И разрабы ЗУПа даже не заметили регистр там или справочник, потому, что используют для работы с транспортами функции из интерфейсного раздела модуля "ОбменДанными". А ты конечно заметил. Потому, что читаешь данные напрямую. Ты и кадровые данные в ЗУП берешь из регистров\справочников а не из представлений? Тогда у тебя впереди еще много таких разочарований.

(0) Гусары, молчать!

(64)
А куда ее лучше поместить, если не в расширение? Я то не против.

Главное, чтобы такие "общие" методы можно было выделить в какой-то отдельный "логический блок" кода. И при этом желательно не снимать с поддержки типовую конфигурацию.

Просто платформа 1С для этого предоставляет очень скудные возможности.
Похоже, что расширение - это единственная из таких возможностей. Разве нет? Какие еще есть варианты?

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