Коллеги, доброго дня!
Есть база УТ11 типовая.
Планируется сильное изменение, поделитесь опытом, куда вносить изменения, чтобы потом было проще обновлять?

Зависит от самих изменений.

(1) по объёму планируется до четверти конфигурации. Документы, справочники, регистры. Скажем так, адаптация для отраслевика.

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

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

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

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

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

(7) Почитаю про новые возможности в последних релизах платформы, если справочники видны между расширениями, то  это очень хорошо

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

(9) ага, про конструктор речь вел

(9) Консоль запросов в режиме Предприятия всё видит, в режиме Конфигуратора конструктор запроса видит:
1. Основная конфигурация - Только Основная конфигурация
2. Расширение1 - Основная конфигурация + Расширение1
3. Расширение2 - Основная конфигурация + Расширение2
правильно?

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

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

(11) Тут не подскажу.

(0) Реквизиты менять в основной конфигурации.
Формы основной конфигурации менять в расширении.
Формы менять программно, т.е. писать код по добавлению реквизитов. (просто стабильно работает, чем изменение мышкой в расширении)
У вас будет некий симбиоз. Как бы вы что-то изменили, и не изменили :)

(11) Если справочники будете добавлять в расширении, то словите баги работы с консолью запросов из обработок.

- Метаданные расширения не доступны из внешних обработок. (я тут про Запросы, СКД и другие работы в конфигураторе)
- Запросы потребуют от вас наличие ссылок на объект метаданных из основной конфигурации.
- не всё в консоли запросов обрабатывается корректно, которые написаны в расширении. Увы, есть баги и странное поведение консоли, которая запускается из текста модуля расширения. (запрос работает, а консоль ругается на ошибки)

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

+(0) Камень в сторону БСП, она некорректно работает с расширением. Есть баги обработки настройки ролей для объектов из расширения.
Про РЛС в расширении тоже забудьте :)

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

(16)
Определяемые типы совсем не работают?

(17)
Совсем про РЛС забыть. Есть проблемы?

(0) Если конфигурация пилится для себя и не планируется её масштабирование на другие базы и/или продажа, то я придерживался бы следующего алгоритма.

0. Разумеется включаем возможность изменения конфигурации с установкой рекурсивно у всех объектов, начиная с корня, правила поддержки "Редактируется с сохранением поддержки". После каждого обновления не забывать устанавливать это правило поддержки для всех добавленных и измененных при обновлении объектов (в соответствующем диалоге, выскакивающем перед выполнением обновления, устанавливать переключатель).
1.  Все новые объекты метаданных (включая роли, общие модули, общие макеты пр. общие), а также новые реквизиты/измерения/ресурсы/табличные части/макеты/формы у существующих объектов конфы поставщика добавлять в самой конфигурации. Никаких расширений.
2. Вся логика работы ваших новых объектов тоже прописывать в самой конфигурации.
3. Подключаемые команды (обработки ввода на основании, обработки заполнения, печатные формы и все прочие отчёты и обработки, включая как самостоятельные так и подключаемые к объектам конфигурации и/или отображаемые на общих панелях), а так же то, что в стародавние времена делалось через внешние отчеты и обработки. Это всё делаем в расширении(ях). Стандартные подсистемы БСП позволяют это делать просто, прозрачно и понятно, с адекватной настройкой ролей и прав, а также встраиванием в командный интерфейс.
4. Доработка форм основой конфигурации поставщика. Если доработка относительна невелика, то делаем это в расширении, стараясь по максимуму использовать программные методы доработки форм (в идеале - только их). Если изменения значительные, то лучшим вариантом может быть не доработка существующей, а создание своей собственной формы. В таком случае свою форму помещаем в саму конфигурацию (расширение тут нафиг не нужно).
5. (Самая сложная часть). Доработка существующих объектов конфигурации поставщика. Какие доработки делать в расширении, а какие в самой конфе? Универсального и единственно верного ответа тут нет. Про добавление реквизитов/ресурсов/измерений/табличных частей и т.п. см. п.1 - добавляем всегда в самой конфе.
А дальше есть два сценария.
А) (пример) Мы решили переписать всю подсистему распределения и расчёта НДС при раздельном учёте. Это как минимум с десяток общих модулей, несколько десятков объектов (документов/справочников/регистров, их модулей, форм и модулей форм). Всё это в разных местах и разных подсистемах. А ещё регламентные процедуры закрытия, регламентированная отчетность и прочая фигня по мелочи, которая вылезет в непредсказуемых местах.
Такое я бы делал в основной конфе. Чтобы при каждом обновлении, когда вендор решит в очередной раз перетасовать все общие модули и в десятый раз перенести экспортные процедуры и функции из одних модулей/объектов в другие, я мог это видеть в окне трёхстороннего сравнения/объединения. Чтобы я имел возможность проанализировать сделанные вендором изменения и НАГЛЯДНО сравнить их с моими. Для крупномасштабных изменений это критически важно. Как бы аккуратно вы не делали доработки в расширении(ях) со всей документацией, после десятого обновления спустя пару лет удержать всё в голове невозможно. А даже самые идеальные тесты никогда не покрывают все 100%.
Б) Относительно небольшие изменения, не вмешивающиеся в какие-либо ключевые и очень сложные разделы и подсистемы учёта. Или эти вмешательства "сбоку" (назовём так) - то есть дополняют, но не ломают и не меняют типовое. Такие доработки лучше делать в расширениях.

В дополнение.
Особенности использования расширений (если доработка делается с их использованием)

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

Небольшие изменения - расширения.
Большие изменения - в основной конфе.

Ретрограды)

(2) "Скажем так, адаптация для отраслевика."
Купить отраслеву и не делать мозг.

(23) Они хотят продать, а ты им предлагаешь купить :))

(19) Нет, в расширении не позволяет редактировать из Основной конфигурации.

(20) Если сможешь из расширения использовать РЛС, напиши. У нас не вышло... Но мало ли, всё дело в сноровке :)

(21) >0. Разумеется включаем возможность изменения конфигурации с установкой рекурсивно у всех объектов, начиная с корня, правила поддержки "Редактируется с сохранением поддержки".

Зачем?
Правило "Редактируется с сохранением поддержки" нужно включать по минимуму и только для тех объектов, которые ты хочешь поменять.
Т.е. если ты планируешь добавлять справочник/документ/модуль/etc... то для корня включаешь, иначе - нет.
Если ты хочешь поменять что-то на форме объекта - то "Редактируется с сохранением поддержки" только для этой формы, а не для всего объекта
И т.п.

(19) Добавить типы из расширения в определяемый тип можно. Лишние типы убрать - нельзя.

(25)
Убрать тип нельзя.
Добавить вроде бы можно.

(26)
Не знаю.
Завел роль в расширении. Вбил в них РЛС.
Вроде бы нормально было.

(29)
*убрать тип из определяемого типа

(30)
Возможно если в двух расширениях разные РЛС, то будет баг.
Память плохая.
Вроде бы РЛС из расширения перекрывают РЛС основной конфигурации.

(0) на инфостарте у GarriSoft была статья (в начале этого года), как вести параллельно две конфы - доработанную и типовую. Там есть интерсные идеи.

(0) Лет 10 уже не трогаю основную конфу, как правило стоит на замке.

Формы в расширении меняются кодом вооот по такому макету:

(27) >> Зачем?

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

Лично я очень долго к этому приходил. Был опыт поддержки очень сильно изменённой БП 3.0. Примерно как у автора - на 20%. Разумеется регулярное обновление - это обязательное условие любой доработки в такой базе. После многократных глюков работы механизма поддержки единственный вариант, работающий без сбоев, был именно таким какой я описал - включаем режим "Редактируется с сохранением поддержки" на корне и рекурсивно на всех(!) объектах, включая те, которые никогда не планируете менять.

На самом деле, когда речь идёт о включении возможности изменения, особого смысла в сохранении режима "Не редактируется" особого смысла нет. Вот оно зачем?
Я понимаю для чего нужно "Снято с поддержки". Это означает, что объект переписан вами вхлам и любые изменения от вендора вам больше не нужны.
Я понимаю для чего нужно "Редактируется с сохранением поддержки". Оно надо, чтобы соединять в одном объекте и изменения/обновления от вендора и изменения/доработки от вас. И при этом видеть в окне трёхстороннего сравнения все изменения - ваши (текущей конфы) по сравнению с конфой поставщика / текущей по сравнению с новой конфой поставщика / и текущей версией поставщика с новой версией поставщика.
Для чего нужно "Не редактируется" - загадка. В особенности, когда оно периодически ломается, когда объект изменён (отличается от конфигурации поставщика), а статус "Не редактируется" (то есть должен быть идентичен версии в конфе поставщика).

(34) понравилось

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

(34) Интересно.
А можно немного поподробнее?
У вас более одного расширения?
Одно расширение "Исправление" с общим модулем для отрисовки интерфейса по шаблонам. Остальные расширения - адаптация под задачи.

(38) У нас 2 основных расширения, которые учитывают друг друга (но это трудно, так как функционал наследования от основной конфы переплетается и это учитывается через отдельный регистр сведений наследования вызовов). В обоих расширениях - рисование реквизитов и элементов на форме, в т.ч. динамических списков и перестановка типовых элементов внутрь наших групп.

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

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

(2)

Это будет параллельная доработка или прям движения по регистрам 1С будете допиливать.

(0) Проект будет провален.
И вообще нет никакого проекта. Просто фигня в виде ветки на мисте...

(41) Ничего не будет. Забейте. Автор - тупой бот. Ветка про несбыточное будущее. Ни о чём.

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

(0)

Ничего не понятно.

Что такое "сильное" изменение ?
Чем оно отличается от "слабого" ?

На мой взгляд, сильное изменение это когда вы пытаетесь изменить или дополнить типовые алгоритмы основываясь на том, как они работают сейчас и поддерживать их работу, учитывая то, как 1С меняет типовые механизмы (привет взаиморасчетам или СО, например).

Еще всякое:
-- Мы решили сделать цену в 5 знаков после запятой (а еще лучше количество или сумму)
-- Написать свой документ(ы) и включить его (их) в расчет ССТ, интеркомпани и всё-всё-всё
-- Дописать "улучшить" интеркомпани
-- выкинуть расчет взаиморасчетов и написать свой с блекджеком и всем остальным

(34) Класс! Надо замутить и вывести заполнение всех форм в один общий модуль по данным макета.

Когда у вас на проекте одна конфа без лишних расширений - вам надо всего одно хранилище для разработки

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

А потом это все еще умножается на количество разных дев/тест/препрод/прод...

(47) EDT же от этого спасет?))) Или нет?

(48) Похоже, что глобально нет. Там будут свои проблемы при объединении доработок.
По факту, + / - одинаково хранилище и EDT. Специально разворачивать последнее имеет смысл при большом количестве разработчиков (от 10 и больше) и потоке доработок, например, делаем нечто уровня УТ или ЕРП (типа отраслёвка)

(49) Угу
EDT а точнее переход с хранилищ на Git требуется когда остро стоит проблема захвата в хранах
И хотят избавиться от бесконечных комментариев в коде

Но появляется новая проблема совмещения доработок, когда некто уже успел вперед в мастер и процедуры/функции пересекаются

(50)+ Для уменьшения проблем совмещения бывает вводят новые правила типа никаких изменений интерфейсов
Это для 1С изменение объявлений процедур/функций

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

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

Если в команде почти никто не знает EDT и главное Git - в жопу их и все пилим через Конфигуратор с хранами

(43)
Скоро на Мисте останутся боты и гуру?
Лет пять и доживем до такого?

(51)
>Т.е. не трогайте старую процедуру/функцию если надо еще параметр добавить - свою новую создавайте и используйте в этом случае
>Но это так же приводит к быстрому разрастанию кода и его дублированию с избыточностью

Ну если это свои процедуры/функции, то можно ввести регламент передачи параметров через структуру.
И тогда этот вопрос снимается.

(53) У меня правила:
1) Нет процедур, только функции.
2) Функция принимает 1-3 основных параметра и допструктуру.
3) Функция всегда возвращает структуру, содержащую поля
Результат - Булево,
ОписаниеОшибки - Строка
Данные - произвольный
КодОшибки - число, опционально, при работе со внешней средой.

(52) >> Скоро на Мисте останутся боты и гуру?

Оглянись! Уже почти так и есть.

>> Лет пять и доживем до такого?

К этому времени останутся только боты.

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

(54) Хз сколько лет назад говорил что Процедуры тупо лишние
Достаточно только Функций
Легко извращаться через Структуры можно только в языках без строгой типизации
И это чревато кучей возможных ошибок

(57) почему? WinAPI всю жизнь так работало на языке С со строгой типизацией. И структурки у какого-нибудь СreateProcess вполне себе некислые.

(58) Что там на C считается структурами это не те Структуры что в 1С
Там это просто общий массив байт, в котором блоки выделены и закреплены за неким именем и форматом
Фактически можно и в 1С так извращаться, всегда один входной параметр строка и один выходной, тоже строка
А внутри строк фигачить JSON ))

(59) как думается мне, структуры - это объекты данных с именованными полями, и в этом плане что в Си struct, что в 1С Структура логически совершенно одинаковы, хотя, конечно, с точки зрения создания и хранения отличия там колоссальные. Подход Hadgehogs в целом наследует классическому API, как его понимают программисты девяностых. И мне кажется, это здраво.

(60) Скажем больше - у меня и в строгом Delphi отлично структуры возвращаются

(61) Жалко, нельзя наследоваться от Record :-)

(60) Я немного о другом
В 1С в структуру всегда можно еще нечто засунуть в рантайме

(63) так у структуры 1С есть замечательная штука .Свойство("ХорошееНазвание"), можно просто проверить, есть ли в структуре данные, которые нам очень нужно обработать
В Си, структура просто описывается в нужном виде и дальше не изменяется

(64) Еще раз
Если описать заранее что может быть в структуре и менять динамически нельзя
Каким местом это будет отличаться от туевой тучи параметров через ","?

Какая нафик разница параметры (причем строго определенного типа) все перечислены в объявлении функции через разделитель?
Или они все внутри одного параметра - составной фиксированной структуры???

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

(66) Это Егор же, это знать надо.
Чтобы добавить параметр в сложном стэке - нужно пробросить его по всему стеку функций. А в случае типовой - позаимствовать в расширение всю шлептучую ветку. Но, хвала типовым разработчикам, там обычно есть структура.

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

Но мы пойдем еще дальше - заведем Структуру, которую положим ВоВременноеХранилище, адрес которой положим в ПараметрСеанса.

Главное, чтобы наш код успел выполниться за 20 минут :-) . Ну и не забивать на синхронизацию - вычищать твою переменную из структуры после выполнения.

(68) И напишем под это дело обвязку типа
АСФОбщегоНазначения.УстановитьПеременнуюВХранилищеПеременных(ИмяПеременной,Значение)
АСФОбщегоНазначения.ПолучитьПеременнуюИзХранилищаПеременных(ИмяПеременной)
АСФОбщегоНазначения.УдалитьПеременнуюИзХранилищаПеременных(ИмяПеременной)

(66) Ну мы же про чистый С говорим же да?
Не про 1С

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

(67) Не знал, не знал, что ты и на С писать умеешь

(70)+ Какая разница передать один указатель на область в памяти или несколько?
Если внутри одного точно так же выделены блоки и приколочены такого же размера как если передать несколько указателей, каждый на свой блок памяти ссылается, где внутри и хранится значение нужного типа

(72) технически разницы особой не будет. Но работать с кодом, где структура, будет заметно поудобней.

(73) С этим согласен, но не совсем
Когда отдельные параметры они сразу контролируются, переданы или нет, значения по умолчанию и т.д.
А если передали структуру или что еще хуже объект - а хз что там внутри, что заполнено
И не поменялся ли уже формат структуры (важно для вызова других dll/so)

(0) Никогда не видел конфы с 20% изменений.Это фантастика.У нас один очень квалифицированный прог дописывал УТ на ОФ три года и очень гордился этим.Результат - менее 2% изменений типового кода,он очень обиделся,когда я посчитал это.
Поэтому не мохнатьте дедушку,снимайте с поддержки и пишите в основной,особливо если типовой код вам только костыль и вы замахнулись на большее...
Я предпочитаю расширения,так как ни на что не претендую,а заменяю логику точечно.Изредка меняю формы,тут как фишка ляжет и программно, и прямо.Не брезгую создавать расширения под каждую задачу.
Иногда спустя время просто удаляю их,если задача стала неактуальной.Удобно.
С некоторых пор храню все сколь нибудь важные данные в конфигурации,даже если работа с ними ведется из расширений.Удобно работать с запросами.
Результат - критически упало время обновлений.Конфигурация обновляется как типовая.Профит заказчика прямой.

(75) Возможно, автор имел ввиду не "переписанная", а "дописанная")
Любой БИТ:чтототам, это надстройка и там написьковерчено бывает и 90%)

(31) Прогрессируют... раньше не было :)

(30) Согласен, может быть мы просто не умеем его готовить :)

(75) 👍