Общие рекомендации по внесению изменений в конфигурацию для последующего облегчения обновления.
Рекомендации по подписям, добавление реквизитов, модулей, форм, процедур...
Все мы не раз сталкивались с обновлением измененных конфигураций. Обычно это долгий и муторный процесс, и почти всегда что-то да теряется из функционала, который до этого старательно добавляли, особенно если это функционал добавляли не вы. Как с этим бороться? Как облегчить себе жизнь?
Вот несколько наработок и правил, которые в этом помогают:
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С, и не обмануть себя по дороге. Разбираю замер Qwen2.5-Coder 1.5B, 3B и 7B на коде с заранее известными дефектами: почему полноту и шум надо считать раздельно, как 3B набирает высокий балл, вообще не читая код, сколько минут уходит на боевую процедуру на процессоре и на GTX 1650, и чем кончилась попытка подложить модели справку по методам платформы.
Железо перестало быть проблемой, и качество ответов немедленно встало в потолок. Дальше пошли три улучшения, каждое из которых выглядело очевидно правильным: свой справочник стандартов, код процедур в поисковом индексе и переписывание вопроса отдельной моделью. Первое работало, но стоило пятнадцать тысяч токенов в каждом запросе. Второе уронило находимость на двадцать процентов. Третье уронило качество с 0,864 до 0,782 и растянуло прогон с 88 секунд до 302. Рассказываю, чем я это померил, почему на глаз ни одно ухудшение не видно и почему добавление правдивой информации регулярно делает поиск хуже.
Расскажем о ситуации, в которой целесообразнее убедиться, что изменение поведения связано с типовой логикой, а не сразу приступать к анализу доработок.
Продолжение статьи «BSL Language Server внутри 1С:EDT: коннектор, которого не хватало». Там мы научили EDT видеть расширенную диагностику BSLLS, а здесь замкнем контур: научим ИИ-агентов автоматически исправлять эти ошибки строго по официальным стандартам разработки 1С.
Вам досталась чужая обработка на полторы тысячи строк. Автор уволился, документации нет, а править её завтра. Обработка читает код за вас: что он делает, что в нём не так и с чего начинать. Всё считается локально, в интернет ничего не уходит.
Рассказываю, как подключить к языковым моделям (в Cursor, VS Code, Claude Code) настоящий Синтакс-помощник 1С - со всеми типами, методами, параметрами, примерами кода, контекстами вызова и версиями платформы. Без ручного парсинга HTML: плагин для 1C:EDT в один клик выгружает официальную справку в Docker-контейнер с MCP-сервером и гибридным поиском (FTS5 + векторный индекс).
Если вы разрабатываете в 1C:EDT, то наверняка знакомы со штатной системой статического анализа через плагин 1C:Code style V8. Но вы также могли заметить, что база встроенных правил давно не обновлялась: последний стабильный релиз плагина вышел ещё в декабре 2023 года. Чтобы вернуть в EDT свежие и актуальные проверки, я форкнул и доработал проект коннектора к BSL Language Server. В этой статье расскажу, как устроена интеграция, зачем она нужна в эпоху LLM и как подключить плагин за пять минут.
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. Проведение будущей датой