Всем привет,

Год назад интересовался практикой использования расширений на крупных проектах. Использование расширений в бою на крупных внедрениях / новые объекты МД в расширении.
Для себя на тот момент понял, что рано идти в историю изоляции отраслевой специфики в отдельном расширении. ОК, от расширения метаданных за счет расширения мы отказались на тот момент и "убедили" в этом интегратора.

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

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

Насколько мне известно, сейчас нет ни того, ни того на рынке. Есть только 3хстороннее сравнение, а сравнить cf и cfe нельзя штатно. Могу ошибаться здесь!

Консультировался когда-то по данному вопросу в 1С, получил ответ: пожелание записано для EDT.


Подскажите, кто пользуется подобным подходом с директивами, как вы потом поддерживаете данный ф-л? Удобно/неудобно на большом объеме изменений?

&ИзменениеИКонтроль - неудобно, по каждому чиху собирать развалившееся.
Я, в целом, все больше прихожу к выводу, что нужно выносить части конфы в расширения, инкапсулируя их в стазисе.

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

Ну и, если не сертифицируетесь на Совместимо - весь корректный зоопарк заимствованных объектов вам и нафиг не нужон.

Со страшилками "А, пропали реквизиты" ни разу не сталкивался.

(3) А у вас есть какая-то сложившаяся практика использования расширений в разработке внутренних продуктов? Если да, то какая?

(2)
на Совместимо не претендуем, Концепцию модульного подхода в архитектуре решений 1С не соблюдаем, продукт исключительно внутренний.

про "динамическое создание реквизитов на форме кодом" - полностью согласен, только так и делаем.

(5) О! Какие проблемы на внутреннем продукте вы решаете с помощью расширений?

(6) Легкое обновление типовой части и отказ от динамического обновления в рабочей базе.

(6) Это было навязанное решение интегратором, отраслевое решение для ERP. Сейчас, избавившись от интегратора, решаю либо в принципе отказаться от использования расширений, либо сохранить что-то в нем для  УПРОЩЕНИЯ дальнейшего сопровождения.

разве под капотом обновления расширения не тоже динамическое?

(9) ну при обновлении 1С ничего не предупреждает :-) С проблемами, как при динамическом, не сталкивались.
Ну и скорость отладки сравнима с внешними обработками, особенно если держать старый сеанс в фоне (для клиент сервера)

(7) То есть все нетиповое в отдельном расширении? Или как?

(0) Моё мнение: на крупных проектах не стал бы использовать механизм расширений.

Причины:
1. Не все объекты поддерживаются в расширении.
2. Бывают ситуации, когда добавленные в расширении реквизиты существующих объектов отваливаются.

По п.2 критичных проблем не было. Решали так: удалили текущий реквизит, добавили новый, значения перетащили.

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

со временем понимаешь, что доработки лучше оставлять в составе конфиги. Расширения и обновления - боль

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

(12) + 1

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

(14) *обновления читать как расширения

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

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

(11) это в 1С и называется Концепция модульного подхода в архитектуре решений, когда есть много отраслевых расширений и каждое пилится отдельным партнером под шилдиком 1С-Совместно

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

Все кто не используют расширения - просто еще не умеют их правильно готовить.
И да https://ru.wikipedia.org/wiki/Серебряной_пули_нет и расширения не серебряная пуля, с ними тоже можно накосячить.
С ними просто удобней чем без них и все.

(12) спасибо за мнение. Согласен про хотфиксы.

(22) Ок, сказал А, говори Б) Вот конкретный пример:
1С декларирует смело свои директивы компиляции, вроде звучит круто.
Бери &Вместо, пиши свой код в расширении и все. В расширяемой конфе объект на замке, это хорошо. Как обновлять потом?

(23) такой же вопрос, как обновлять "&Вместо"

(20) Фига себе, а я проспал всю движуху! Наоборот, помнил еще как 1С в начале открещивались что мол "не-не-не, расширения - это не про модульность, окститесь, не надо их в ту сторону форсить".

(23) &Вместо надо писать в последнюю очередь, сначала попытаться &Перед или &После решить проблему/задачу

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

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

И да на "крупных внедрениях" пора переходить на EDT с Git, ибо там трёхстороннее сравнение и объединение и выделение фич по веткам и единственный вариант совместной разработки большой команды почти не мешая друг другу что часто с Хранилищем

Короче, я для себя понял так.
Расширения - удобная альтернатива нескольким конфигурациям поставщика.

(23) 1С как раз - таки декларирует использовать Вместо крайне осторожно и в исключительных случаях. После полноценного внедрения Изменение и контроль( ждем совместимости типовых с 8.3.15), про Вместо вообще лучше забыть. А пока искать способы модернизировать код с Перед и После

&Вместо вообще лучше не использовать. Это как мина замедленного действия - никогда не знаешь, когда рванет.

+31. Как вариант &ИзменениеИКонтроль. Но на больших проектах это скорее проблема, чем решение.

(18) Вы к нам прямо из 2015 ого?

(12) +100500

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

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

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

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

Правки в типовом функционале сводятся в основном к модулям "расширяемый" ну и добавления своих типов в общие типы и подписки.

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

(23) >> Бери &Вместо, пиши свой код в расширении и все. В расширяемой конфе объект на замке, это хорошо. Как обновлять потом?

Да какая разница - &Вместо, &Перед или &После?

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

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

(35)
Хорошая практика. Тоже используем по данному назначению.

Согласен с (12)
Расширения только так.. подлатать быстренько что-нибудь..
Если более-менее большая доработка, удобнее "вскрыть" конфу и работать по старинке..

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

(33) что то изменилось с тех пор ?

(37) разница есть, если использовать например "&После" можно добавить свои реквизиты на форму, после процедуры "при создании на сервере", вряд ли ее переименуют, даже если перепишут, расширение должно будет работать.

(33) да и причем тут 2015г ?

(41) >> вряд ли ее переименуют.

С каких пор "вряд ли" стало мерилом гарантии? Даже смешно обсуждать.

>> если перепишут, расширение должно будет работать.

Никто не спорит, что расширение будет работать.
Вопрос в том - как?
Если расширение не отвалилось с синтаксической ошибкой - значит ли это, что оно работает?
А то, что код, ради которого было написано расширение перестал вызываться и работать - это нормально? Или смысл работы этого кода потерялся т.к. поставщик полностью переработал форму и логику её работы?

(3) я сталкивался. Зашло обновление на ЗУП с волшебным переименованием измерения в "СотрудникУдалить" расширение отвалилось после апдейта студентом из франча и похерились все данные объектов расширения.

(44) до слез

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

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

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

(46) дай дуракам хрустальный хер...

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

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

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

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

(49) Что такое "испорченные" записи/объекты? И как можно добиться того, что при включенном расширении добавленные поля будут проигнорированы?

(50) при выключенном, но до его удаления

(51) т.е. по идее, поля остаются. Но доступа на запись в эти поля нет. Их никто "не видит". Перезапись этого объекта и данных ёк

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

Похоже, отчет на 4-х стороннее сравнение стоит дописать.
Думал, 1С эту область закрыла каким-то своим решением.

(52) Погоди-погоди. То есть, если перезаписать объект с добавленными реквизитами при отключенном расширении, то данные в добавленных реквизитах очищаются? Японский городовой! Чуял я, что есть где-то засада :)

(55) Не, я все понимаю, если мы по взрослому платформу ваяем, то

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

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

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

не особо можно общие модули расширять. В регзаданиях пишет

Ошибка расширения модуля 'ОбщийМодуль.ПродажиСервер.Модуль': расширение модуля запрещено из-за того, что расширение 'Расш' подключено в безопасном режиме

(56) Нифига не интуитивно. Интуитивно - не трогать значения добавленных реквизитов при перезаписи объекта и отключенном расширении.

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

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

(60) Хороший компромисс. Чувствуется рука бывалого параноика :)
Единственное, не понял как с правами. Можно давать права в основной на объекты расширения?

(61) так я же написал. Все таблицы и права в основной

(62) Туплю

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

(64) за одного битого двух небитых дают

(65) сисадмин клиента начитался и потребовал в ТЗ сделать именно так. Обновлять типо проще потом ))) По факту юзаю расширения, только если костыль какой вставить. Новые объекты\реквизиты только в основную конфигурацию во избежание так сказать.

(60) на расширенияХ или основном расширении+заплатки/патчи. если их много, то как следите кто что кодит и кто кого расширяет?

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

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

Мой опыт: 5 лет все доработки только через расширения. У клиентов всегда актуальные типовые, что немаловажно в эпоху цифровизации и тотальной маркировки.
Ищите "фреймворк для расширений")

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

(23) "В расширяемой конфе объект на замке, это хорошо. Как обновлять потом?"
Какие проблемы? Обновил штатно и гори там всё синим пламенем. Ведь 99% хотелок, реализуемых расширениями - это хотелки менеджеров, которые меняются чаще, чем обновляется 1с))

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

(73)например можно обновлять по принципу(72).

(0) В расширениях используем только директивы &Перед и &После. Если нужны изменения внутри метода, то меняем в основной конфигурации. Новые объекты добавляем только в основную конфигурацию. Интерфейс изменяем в расширении декларативно. Расширения начали использовать еще начиная с версии ERP 2.2, сейчас ERP 2.4. ,т.е. уже более двух лет. За все время проблем с обновлениями особых не было. С новыми версиями платформы, время от времени, добавляется новые самопроверки платформы на применимость расширения.

(75) скажите пожалуйста, как Вы проверяете расширения на работоспособность при обновлениях на мажорный релиз (аля 2.2-> 2.4 или 2.4 -> 2.5)?

(76) Сначала прогоняем дымовыми тестами, потом вручную сценарным тестированием. Автоматическое сценарное тестирование не используем.

(77) спасибо за информацию!

(0) В крупных внедрениях не используем.Для доработок всевозможных хотелок и багфиксов расширения оказались очень удобны-> в багаже более полусотни.

Я вот сделал доп.реквизит объекта по ГТД в расширении у клиента. так меня потом месяц совесть мучала, что не в конфу добавил, а в расширение. Ведь конфа была модифицированная.
Не делайте так. Расширения для кода, а не для доп.полей, ну разве что если в конфу на поддержке.

Рекомендую плодить не зоопарк из 40 мелких расширений, а 2-3 и поддерживать их через хранилища. Иначе не проконтролируете. Всё.

(77) Грамотное название отсутствия тестирования :) Возьму на вооружение :)

Ответов уже больше, чем в прошлом году)) Т.е. механизм развивается, хоть и очень "осторожно"

Для себя понял три основных тренда/ этапа принятия расширений.
1. Не использовать расширения в принципе, кроме хотфиксов
2  Использовать по принципу, как и описал в (0), только для программного расширения модулей поставщика с директивами После, Перед.  
3. Использовать для полноценной изоляции определенного ф-ла (расширение данных, программное расширение модулей) Тот самый модульный подход 1С. На текущий момент к нему готовы только в 1С :)

Пока остановлюсь на этапе 1. Подожду полноценного развития механизма.
Спасибо большое за ответы!