Общие рекомендации по внесению изменений в конфигурацию для последующего облегчения обновления.
Рекомендации по подписям, добавление реквизитов, модулей, форм, процедур...
Все мы не раз сталкивались с обновлением измененных конфигураций. Обычно это долгий и муторный процесс, и почти всегда что-то да теряется из функционала, который до этого старательно добавляли, особенно если это функционал добавляли не вы. Как с этим бороться? Как облегчить себе жизнь?
Вот несколько наработок и правил, которые в этом помогают:
1) Подписи.
Все мы обычно подписываемся так:
///Тима - Тима для примера, может быть вася петя инициалы итд
Но это не совсем верно: если в глобальном поиске набрать "Тима", то вылезет куча не нужных вещей, например "Функция дкПривестиМакетПечатнойФормы(ЭтотОбъект,Макет)". (Хотя можно искать и "/Тима"
поэтому лучше подписываться латинскими буквами!
Дальше нам надо, к примеру, изменить знак в строке)
Переменная = Переменная - 1; ///TIMA
Если мы подпишемся так, то это будет не очень ясно, а писать в комментарии, что конкретно изменил не всегда получается понятно другому человеку, поэтому лучше комментировать все строки, которые вы изменяете, а ниже уже писать свои:
И если вы изменяете целый блог то лучше еще вставить начало изменений и конец изменений.:
///Tima +++ (а лучше и написать дату изменения, чтоб было легче вспоминать) 230813
///Переменная = Переменная + 1;
Переменная = Переменная - 1;
///Tima -
Также если работает несколько человек над одной конфигурации, то перед именем в подписи вставьте что-то общее, например имя организации, для которой вы все это меняете:
///RogaAndKopita Tima +++ (а лучше и написать дату изменения, чтоб было легче вспоминать) 230813
///Переменная = Переменная + 1;
Переменная = Переменная - 1;
///RogaAndKopita Tima -
2) Подписки на события!
Ну конечно же во-первых и во-вторых используйте Подписки на события.
Порядок выполнения подписки на событие не регламентирован, пишите код исходя из этого.
3) Добавление реквизитов, модулей, форм итд
Все новые объекты конфигурации добавляете с префиксом (например, "Dop_" или "RogaAndKopita_" или "Tima_").
То же самое касается и новых функций или процедур.
4) Добавление новых процедур
Все новыее процедуры и функции добавляете в СВОЙ общий модуль, по возможности не трогайте типовые!
Старайтесь как можно больше процедур и функций помещать в СВОЙ общий модуль, вы себе этим здорово облегчите жизнь.
Если вы забудете, что вносили изменения и затрете свои или чужие наработки, то гораздо легче найти место, куда вставлять вызов процедуры, чем восстанавливать всю процедуру заново.
5) Изменения в формах.
Если хотите изменить события формы или обработки реквизитов, то есть 2 способа
Первый способ.
Если хотите изменить события формы или обработки реквизитов, то есть 2 способа
Процедура ДопПриОткрытии()
///Сюда вставляем что хотим до
Выполнить(допПолучитьСтароеДействиеФормы(ЭтаФорма, "ПриОткрытии"));
///Сюда тоже можно вставлять
КонецПроцедуры
Второй способ.
Позаимствовал у компании Рарус обработку реквизитов: в модуле формы во все требуемые процедуры пишем строчку:
///Если Обрабатываем ТабЧасть:
ОбработкаРеквизита("ИмяТабЧасти.ИмяРекизита", ЭлементыФормы.ИмяТабЧасти.ТекущаяСтрока, ЭтаФорма);
///Если обрабатываем реквизит формы или событие:
ОбработкаРеквизита("ИмяРекизита", , ЭтаФорма);
А в модуле документа делаем:
Функция ОбработкаРеквизита(Имя,ТекСтрока=Неопределено,ЭтаФорма=Неопределено,ДопПараметры=Неопределено) Экспорт
Если имя = "ИмяРекизита" тогда
ИначеЕсли имя = "ИмяРекизитаДругого" тогда
//А если надо вызвать обработку другого реквизита при выполнении кода это делается легко:
возврат ОбработкаРеквизита("ИмяРекизита", , ЭтаФорма);
Иначе
//// А тут можно сделать вызов такой же функции в общем модуле для изменения общих реквизитов (например ставка НДС)
Возврат ДопОбработкаРеквизита(Имя,ТекСтрока,ЭтаФорма,ДопПараметры);
КонецЕсли;
КонецФункции
6) Изменение самой формы
Если нужно изменить саму форму, например добавить реквизит или еще что-то, можно использовать декомпилятор форм:
А код из декомпилятора вставлять в процедуру ПриОткрытии (конечно с учетом 5-го пункта)
А вот если требуется сильно переделать всю форму, то советую создавать новую форму, тогда при обновлении всего лишь переопределится форма по умолчанию, а все ваши изменения не потеряются.
Вот собственно и все приемы, которые я знаю. Если знаете еще способы, то пишите, обязательно их добавлю.
Внешняя обработка для статического анализа исходников 1С без изменения данных базы. Помогает перед релизом или публикацией быстро проверить код на рискованные вызовы, интеграции, файловые операции и возможные секреты. Проверяемый код не выполняется, найденные пароли и токены маскируются.
На проекте сложного обновления 1С:ERP 2.4.14.181 до версии 2.5.22.106 нам было нужно уложить обновление в технологическое окно 48 часов (выходные). Исходный замер, с учетом промежуточных релизов 2.5.8.443, 2.5.12.270, 2.5.17.234, 2.5.22.106, показал требуемое время в 659 часов…
Обновление ролей в расширении 1С отличается от аналогичного процесса в основной конфигурации. Ситуация осложняется, когда доработки вносятся не в «обычное», а в поставляемое расширение.
Code review в 1С часто превращается в спор вкусов: “мне не нравится”, “переделай”, “так не делают”. В статье разбираю другой подход: проверять не разработчика, а риск для системы. Показываю, как формулировать замечания без токсичности, где заканчивается личное предпочтение и начинается реальная проблема, почему ревью должно развивать разработчика, а не только исправлять код
Показываем, как встроить ИИ-помощника в code review 1С без Git, SonarQube и EDT – только с Конфигуратором, RAG-контекстом и набором MCP-инструментов. Разбираем архитектуру решения на Open Web UI и OpenRouter, методику сравнения моделей по Precision, Recall, BonusRate и PenaltyRate, а также объясняем, почему контекст влияет на качество ревью сильнее, чем выбор самой модели. На реальных примерах показываем, какие ошибки ИИ находит хорошо, где все еще нужен архитектор и почему на старте пилота время ревью может не сократиться, а вырасти. В финале делимся метриками внедрения и выводами для команд, которые хотят повторить такой подход у себя.
Кажется, что code-review с помощью искусственного интеллекта устроено просто: достаточно отправить код в LLM, задать промт и получить список замечаний. На практике такой подход быстро упирается в недетерминированность результата, неверную оценку критичности ошибок в 1С-коде и рекомендации, которые сложно отличить от полезных замечаний. Описываем гибридный подход к автокод-ревью: статический анализатор работает вместе с LLM, а база знаний из стандартов 1С превращается в набор машиночитаемых норм. Такая архитектура помогает снизить количество галлюцинаций, точнее определять критичность нарушений и постепенно развивать качество ревью через итеративное пополнение правил.
Чем активнее развивается старая система, тем страшнее бывает её менять. Снаружи всё выглядит живым: релизы выходят, бизнес получает новые функции, пользователи работают. Но внутри уже появляются фразы, после которых разговор заканчивается: «это лучше не трогать», «там когда-то всё упало», «давайте сделаем рядом». И в какой-то момент становится непонятно: система ещё развивается — или команда уже просто учится обходить опасные места.
MetaVision for 1C PRO — профессиональная версия статического анализатора и визуализатора кода. Загружает выгрузки конфигураций, расширения и внешние файлы, за секунды строит графы функций, находит уязвимости безопасности и подсвечивает проблемы производительности. В арсенале: визуализация логики в виде графов условий, циклов, транзакций и вызовов, статический аудит безопасности с поиском RCE, SSRF, COM-инъекций и паролей в коде, выявление запросов в циклах и вложенных блокировок, полнотекстовый поиск по всем модулям, встроенный редактор с конвертером запросов и автоформатированием, а также честная статистика по объектам и функциям. Главное новшество PRO — до пяти конфигураций одновременно с мгновенным переключением, наложение до пяти расширений как в конфигураторе, анализ внешних файлов в единой связке с основной конфигурацией и пять тем оформления. Инструмент для тех, кто ведёт несколько проектов параллельно и хочет видеть полную картину в одном окне — быстро, наглядно и безопасно.
1. Если меняется одна строка, то лучше писать комментарий в той же строке или перед ней.
Со временем таких изменений будет несколько и код может выглядеть как елка - всё зеленое от почти бессмысленных комментариев.
Да и причину писать надо. Бывает на одну строку кода пишешь 2-3 строки комментария.
Переменная = Переменная - 1; ///RogaAndKopita Tima +++ вместо "+" будет "-" потому что <причина действий> 230813
2. Все новые процедуры и функции добавляете в СВОЙ общий модуль, по возможности не трогайте типовые!
Частично согласен. Но я бы советовал не один модуль, а несколько. Разделить их, во-первых, по направлениям/участкам работы. Во-вторых, на клиентскую и серверную часть.
И не стоит скидывать со счетов модули менеджеров - очень полезная вещь, особенно, если функция или процедура работает только с одним видом объекта конфигурации.
3. Могу предложить еще вариант "триггеров" - некий справочник, в котором хранится код 1С, вызываемый в тех или иных случаях - динамическое изменение кода, универсальность встраивания.
Подписки хороши, если мы что-то делаем "по факту" и с целым объектом. А если нам надо в форме документа проверять реквизит на какие-то условия?
Если условий 5-10 штук, они меняются раз в месяц, да еще зависят от второй буквы девичьей фамилии матери отца соседа снизу пользователя?
Вот тут и пригодится такой внешний код - вызов займет 1-2 строки, при встраивании в типовую конфигурацию удобнее обновлять несколько строк, чем "километры" кода.
4. Для изменяемых объектов типовой конфигурации можно завести отдельную подсистему "ВрезкаВТиповую" и включать объекты в случае их изменения - это позволит в случае "врезок" либо исправления ошибок до выхода новой версии типовой фиксировать измененные объекты чтобы отслеживать их при обновлении.
1 пункт, если в типовые модули делать минимум изменений то как елка код не будет выглядеть, а в доп модулях комментировать все не обязательно.
2 пункт да, видно надо было расширить в статье это.
3 пункт получается аналог внешнего модуля, просто изменения можно внедрять не залезая в конфигуратор. Такой вариант тоже имеет право на жизнь.
Главное обновляй конфу поставщика нормально и все твои врезки будут видны и понятны ибо никакие комментарии не помогут понять, что же цензура сделали в этой конфе, где версия cf 3.0.2, а версия поставщика 1.0.1 ...
А такие комментарии нафиг не нужны, т.к. они больше похожи на написанное на заборе "Сдесь был Вася!" , "Выпуск 1986г."...
(105) Gazza, "завести отдельную подсистему "ВрезкаВТиповую"" - я пришел к выводу о том, лучше делать следующую иерархию подсистем - первая МоиПодсистемы, и ей подчиненные МоиДобавленныеОбъекты, ОбъектыТиповойИзмененные,ИсправленныеОбъектыТиповойСОшибками.
В первую добавляем свои объекты - удобнее просматривать что добавлено, вторая подсистема позволяет контролировать а не слетели ли доработки, а третья контролировать глюки типовой которые в следующем релизе могут быть исправлены.
(105) Gazza, не согласен. Когда есть список заявок и в комментах писать не вася, а №заявки такой. то потом можно: а) узнать зачем вносились изменения и с какими объектами они связаны; б) проще искать изменения;
//--> I.F. Проведение будущей датой
Процедура ОбработчикИзмененияДаты(Данные)
Если Данные="ДокументОбъект.Дата" ИЛИ Данные="" Тогда
Если Дата>ТекущаяДата() Тогда
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.НеОперативный;
Иначе
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.Оперативный;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
//<-- I.F. Проведение будущей датой
//...
////////////////////////////////////////////////////////////////////////////////
// ОПЕРАТОРЫ ОСНОВНОЙ ПРОГРАММЫ
//...
//--> I.F. Проведение будущей датой
ПодключитьОбработчикИзмененияДанных("Дата","ОбработчикИзмененияДаты");
//<-- I.F. Проведение будущей датой