Кто-нибудь всю кастомизацию в расширение запихивал?
Или только багофиксы и небольшие допилы?

Мелочевка пока

Запихивал. Реквизиты. Теперь документ в журнале не регистрируется, собака женского рода такая. Помогает только удаление расширения и ТИИ

Платформа 8.3.13.1644

(0) багофиксы допилы.

(3) На 15 вроде говорят с этим делом веселее

(2) Это как?

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

(0) а есть методика обновления сложных расширений ?

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

(7) Прикольно...

(0) У меня нет. Только начал пилить.

ERP пилю только в расширении :)

(0) Большие расширения не делал, сравнительно небольших больше десятка наклепал, размером со среднюю обработку, ну может тысяч на 5 строк от силы. Без изменений, требующих реструктуризации, т.е. без изменений в СУБД. Еще столько же всяко-разных полуодноразовых патчей делал.

(9) (11) Похоже все гуд?

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

На сегодняшний день расширения подходят только для.
1. Временные патчи, которые в дальнейшем будут либо включены в конфигурацию, либо отключены и удалены.
2. Подключаемые отчеты, обработки и печатные формы. То что раньше, до БСП 2.5, называлось внешними отчетам и обработками.
3. Минимальные доработки управляемых форм. Типа свой реквизитик выложить и обработчики его событий. Да и то только в том случае, если они никак не завязаны с типовой конфигурацией, которую поставщик может в любой момент перелопатить.
4. Какие-то совсем минимальные доработки, которые легко будет быстро поверить и протестировать при обновлениях. Да и то - как правило лучше в самой конфе.

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

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

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

(0) были попытки в начале полностью уйти в типовые, где можно, перенеся все потом в расширение. Пройден путь от множества расширений в одной конфе - одно под какую-то фичу, к - единому аккумулятивному расширению, содержащее все фичи/фиксы и прочее. Почему так - потому что по другому команде уже не удобно работать с общей конфигурацией (расширяемая + основная). Я сделал свое расширение, Петя - другое, Васёк - еще два - как нам синхронно понимать через единое хранилище, что мы вообще натворили? Ну, никак без костыля: делаем макеты под каждое расширение, их туда сохраняем, затем каждый свое захватывает. Время релиза, вожатый дает команду - сли-и-и-и-и-и-ваем! Кто-то один садится, и начинает делать мега-расширение или тестить этот слоеный пирог из расширений.

Поэтому решили уйти - к одному мега-расширению, которое кладем в +1 хранилище к основному (что уже радует). Опять же, нужно держать +1 хранилище, и уже работать с минимум двумя. Что совсем всё это обесценивает.

Опять же, я описал только механику работу с расширениями в команде. Не описывал саму физику обновления расширения. Есть дельная статья на исе, ее можно почитать вместе с комментами: http://catalog.mista.ru/public/1039552/

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

Надеюсь, в будущем, все эти косяки как-то пофиксят.

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

хз, я целые подсистемы на расширении делаю и норм. Проблем с обновлением ЕРП не было. Платформа последняя 15

(14) очень спорно, в ваших словах столько боли, что я делаю вывод,
что вы просто делали не расширения, а костыли.

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

(15)  во взрослых языках такой способ - это пулл реквесты и мердж

(17) Всё более или менее нормально работает, если расширение не касается типовых объектов. Пиши хоть целый дубль всего ERP.

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

(20) само собой адаптация конфы под тек. требования происходит. В расширении создаю новые объекты/реквизиты, правда выводить стараюсь программно.

(20) имею виду доработка типового фунционала

(17) ты один работаешь и твои подсистемы все, очевидно, сбоку от типового функционала.
(19) Да, но мерджить то хочется автоматом :) И если выбирать сейчас между обновлением доработанной и обновлением типовой + обновления расширения + тестирования расширения, то второй вариант совсем плохой. И еще - если возится с обновлениями доработанной не хочется, можно отдать эту работу на сторону, и вообще забыть про все это как страшный сон.

(18) >> прочитал вас пост как в луже повалялся.

Значит вы что-то не поняли из того, что я написал. Сожалею.

>> ... это ж надо быть таким криворуким.

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

(24) Почему не используете тестирование?

(18) >> вы просто делали не расширения, а костыли.

А чем расширения отличаются от костылей?...
По сути расширение - это и есть костыль. Когда у вас нет возможности модернизировать исходный (расширяемый) объект, приходится его расширять. Причем без какой-либо возможности дальнейшего автоматического анализа того, что вы там понарсширяли. Только глазками смотреть, читать комментарии в коде (если разработчик не поленился их сделать) и документацию к расширению (если методисты не поленились её нормально написать). А если расширений более одного, то попытка понять - как это всё работает совместно и вообще совместимо ли - превращается в целый квест.

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

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

(25) >> Почему не используете тестирование?

Где написано, что мы его не используем?
Часть косяков как раз выявляется при тестировании.

Но с тестированием есть две проблемы.
1. Проблема в том, что невозможно протестировать всё. Это слишком трудозатратно.
От написания автоматизированных тестов мы отказались, т.к. на это просто нет ресурсов. Для создания таких тестов, которые покрыли хотя бы 80% фукнционала, уйдёт пара человеко-месяцев. Плюс эти тесты при каждом обновлении надо будет тоже актуализировать с учётом изменений.
2. Пользовательское тестирование даже только основных бизнес-процессов может занимать времени больше, чем само обновление. Никто не готов выделять такие ресурсы.

(27) >> расширение - это почти ВПФ или обработки :) Со всеми вытекающими.

Это мы понимаем ))

>> Если ты в них используешь что-то из типового функционала, и оное - меняется, то изучение того - что изменилось и изменилось ли, выявление этого факта - это твоя работа :)

Разумеется. Именно в этом проблема.
На порядок проще такой анализ сделать в ходе трёхстороннего сравнения-объединения при обновлении, чем пытаться глазами сделать анализ нескольких расширений.

>> ...не используй БСП и типовые механизмы, пиши все с нуля сам...

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

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

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

Занимательно. Похоже придется самому походить по граблям.

(15) Интересная статья.

(27) так обновление на стороне не гарантирует качества этого обновления
ну и тесты должны писать сами разарботчики функционала

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

(30) >> Интересная статья. в (15)

+100. Примерно то же самое я хотел сказать своими постами. Только немного другими словами.
Автор статьи делает примерно такие же выводы, как и я. Использовать расширения целесообразно  только там, где нельзя менять типовую, где нужно тиражирование (мы так тоже делаем), и для работы с Git (мы с Git не работаем - для нас неактуально).

не используешь БСП – уволен ;-)

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

(35) в этом свете забавно выглядят вопли разных товарищей про отсутствие ООПия в 1с.

(35) >> в типовых переименовывают общий модуль/метод и усё, расширение не работает.

Хорошо, если расширение при этом хотя бы ругнулось. Сообщило о невозможности применения или вывалилось с ошибкой исполнения кода при тестировании или даже в продуктиве. Ты находишь ошибку, исправляешь и живешь дальше.
А то ведь бывает, что расширение перестаёт работать молча. Из-за того, что расширенная тобою процедура просто ниоткуда больше не вызывается. Её работу 1С-овцы перенесли в другое место. Об этом ты можешь узнать спустя несколько месяцев при закрытии периода, когда пользователи тебе предъявят, например, что сделанная тобою доработка по автоматическому заполнению какого-нибудь реквизита в регистре, справочнике или документе не работает.

(37) от этого прикола наличие вашей доработки внутри конфиги а не сбоку никак не защищает.

Пробовали. Словили очень много геморроя. Отказались. Для себя решили, что единственное логичное использование расширений - патчи на ошибки между своими релизами корпоративной системы.
Еще одна проблема: мы долго используем релизы платформы (больше года), т.к. переход на новую требует серьезных ресурсов (тестирование прежде всего). Сейчас у нас на продуктивном сервере 8.3.12, а в ней очень многого для расширений нет.

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

(38) >> от этого прикола наличие вашей доработки внутри конфиги а не сбоку никак не защищает.

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

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

(30) // Занимательно. Похоже придется самому походить по граблям.

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

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

(42) >> преимущество - можно функционал пилить не выгоняя пользюков из базы.

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

(42) Поясни, непонятно. Чем это отличается от обычной разработки и динамического обновления.

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

(44) А мы делаем динамическое обновление. И периодически база падает. И все равно делаем. Требование бизнеса. Функционал меняется на лету.

(0) На одном проекте используем очень активно. Очень большое количество баз на РИБ (несколько сотен) и через конфигурацию обновлять проблемно, а постоянно надо что то фиксить. В итоге сделали отдельное расширение, которое может обновлять расширения :) До этого тех поддержка в ручную эти расширения накатывала и если прогер ошибся, они охреневали, надо было все заново ставить.  
Палка о двух концах. То что какие то там баги есть с расширениями, это все ерунда. При активной работе с расширениями, все эти баги знаешь. Там другие проблемы. Перед тем как типовую обновлять, надо будущий релиз типовой тестить на совместимость с уже имеющимся расширением.  Бывало таким образом переставал работать какой то важный функционал, а узнавали уже когда было поздно. Иногда от контролирующих организаций, когда штрафы приходили. Ну и в итоге, то от чего расширение должно нас избавить, от проблем с обновлениями, по факту остается, просто выглядит по другому. Поэтому нужно понимать, где есть в расширениях смысл, а где его не будет. Если в расширениях что то критичное, то просто так типовую обновлять нельзя.
Сумбурно, но надеюсь что то понятно.

(45) >> Чем это отличается от обычной разработки и динамического обновления.

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

(47) >> периодически база падает. И все равно делаем. Требование бизнеса.

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

Мы тоже сначала так делали. Потом прикинули реальные риски от того, что будет, если база рухнет таким образом, что её не удастся поднять привычным образом.
Решение нашлось сразу. Все обновления только в технологические окна, когда из базы всех выгоняют. В исключительных ситуациях при согласовании с руководством - рассылка о том, что все идут курить на 10 минут.
Парадокс в том, что после этого выяснилось, что исключительные ситуации случаются раз в месяц. А в остальных 99% случаев все вполне готовы потерпеть до завтра, когда выйдет ночная сборка.

Мелкие фиксы которые не пойдут в релиз или должны быть доступны до релиза.
Например фикс загрузки методической модели в УХ, загрузка формул в вид отчёта на клиенте (типовой на сервере делает через com, а там Линукс).
Если в 2х словах - функционал с коротким сроком жизни или сроком жизни до полноценного релиза.
Делать что то серьезное на расширении - пока только рано или поздно происходит натык или на баг или на ограничение.

Делал в расширении доп справочник и реквизит типового справочника. На одной платформе 1С (8.3.13) просто падала (гуглил ошибку - ничего нет). Пересобирал расширение с нуля на платформе клиента, не помогло. Пришлось обновлять клиента до последней платформы, на которое расширение нормально работало.
А так, у нас в качестве корпоративной стоит УТ, сильно допиленная расширением. Всё стабильно

Если в двух словах то "Расширение - наше все".

8.3.13.1644, УНФ. Кастомизация на 90% там. В конфигурацию добавляю только новые объекты, связанные с хранением данных учёта. РС, хранящие настройки, актуальные для допила, и т.п. храню в расширении - если и рухнет что, заново вколотить 2 минуты. Пока тьфу-тьфу.