Как правильно оформить изменение типового кода 1С при доработке конфигурации?

← На главную

При сопровождении и развитии информационных систем на платформе «1С:Предприятие» (особенно таких крупных и нагруженных решений, как «1С:УПП») разработчики регулярно сталкиваются с необходимостью кастомизации типового функционала. Даже минимальное изменение, например добавление одного слагаемого в расчетную формулу внутри типового отчета или проведения документа, ставит перед программистом важный вопрос: как оформить доработку так, чтобы не превратить последующее обновление конфигурации в кошмар?

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

Постановка задачи и анализ вариантов ручной правки

Рассмотрим классическую ситуацию: внутри типового отчета или модуля нам необходимо изменить всего одну строку кода, добавив к результату вычисления свое слагаемое. Представим исходную строку кода:

бла-бла-бла = Выборка.ЗначениеПоказателя;

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

Вариант №1: Полная замена строки с комментированием старой


//мой код
//бла-бла-бла = Выборка.ЗначениеПоказателя;
бла-бла-бла = Выборка.ЗначениеПоказателя + МояДобавка;
//мой код

Вариант №2: Перенос новой логики на следующую строку без изменения исходной


бла-бла-бла = Выборка.ЗначениеПоказателя
//мой код
+ МояДобавка;
//мой код

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

Почему Вариант №2 категорически не рекомендуется?

На первый взгляд, Вариант №2 кажется привлекательным, поскольку мы не трогаем оригинальную строку кода. Нам кажется, что при обновлении системы автоматический трехсторонний merge (слияние) легко сопоставит исходную строку поставщика. Однако на практике такой подход порождает серьезные проблемы:

Нарушение стандартов публичного кода и читаемости: Разбиение целостной синтаксической конструкции на несколько строк с разрывом посреди оператора сложения ухудшает читаемость модуля. Программисту, который будет читать этот код после вас, придется тратить дополнительное время на сборку выражения в голове.
Ошибки автоматических анализаторов (линтеров): Современные системы автоматической проверки качества кода (например, SonarQube или BSL Language Server) настроены на строгие стандарты форматирования. Подобный разрыв строки с внедрением комментариев между операндами гарантированно вызовет предупреждения или ошибки при проверке кода (Quality Gates).
Сложности при сравнении и объединении: Инструменты сравнения файлов в платформе «1С:Предприятие» работают построчно. Разорванная строка усложняет сопоставление блоков. При обновлении конфигурации велика вероятность того, что добавленная часть + МояДобавка; «оторвется» от основного контекста или затрется, что приведет к труднодиагностируемым синтаксическим ошибкам на этапе компиляции.

Вариант №1: Классический стандарт доработки и правила его оформления

Вариант №1 является общепринятым и наиболее безопасным при ручном изменении кода в основной конфигурации. Мы четко фиксируем состояние системы «до» нашего вмешательства и наглядно показываем состояние «после». Однако просто закомментировать строку «двумя слэшами» недостаточно. Чтобы код оставался профессиональным и понятным при последующих обновлениях, необходимо придерживаться жестких правил комментирования.

Рассмотрим, как правильно оформить такое изменение по стандарту фирмы «1С»:


//++ Ivanov_AA 15.10.2026 Task_98765 Изменение формулы расчета показателя
// Было: 
// бла-бла-бла = Выборка.ЗначениеПоказателя;
бла-бла-бла = Выборка.ЗначениеПоказателя + МояДобавка;
//-- Ivanov_AA 15.10.2026

Разберем детально структуру этого блока:

Тег //++ наглядно обозначает начало измененного блока кода.
Указание фамилии автора (Ivanov_AA), даты внесения изменений (15.10.2026) и номера задачи из трекера (Task_98765) позволяет мгновенно восстановить контекст: кто, когда и зачем внес эту правку.
Метка // Было: четко указывает на оригинальный код вендора. При обновлении программист сразу увидит, изменилась ли типовая строка в новой версии конфигурации от поставщика.
Тег //-- обозначает завершение измененного фрагмента.

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

Современный подход: Перенос доработок в расширения конфигурации

Если ваша информационная система работает на платформе «1С:Предприятие 8.3» (начиная с версии 8.3.15 и выше), то наиболее правильным решением будет полный отказ от изменения кода в основной конфигурации. Для этого мы задействуем механизм расширений конфигурации.

Использование расширений позволяет оставить основную конфигурацию на полной поддержке поставщика (на «замке»), что в десятки раз ускоряет процесс последующих обновлений. Для решения нашей задачи идеально подходит аннотация &ИзменениеИКонтроль.

Давайте разберем по шагам, как это реализовать:

Создаем новое расширение конфигурации (или используем существующее корпоративное расширение для доработок).
Заимствуем в расширение процедуру или функцию, внутри которой находится наша целевая строка.
Применяем к методу аннотацию &ИзменениеИКонтроль.
Используем специальные платформенные директивы совмещения кода: #Удаление / #КонецУдаления и #Вставка / #КонецВставки.

Посмотрим на пример реализации в модуле расширения:


&ИзменениеИКонтроль("ЗаполнитьПоказателиОтчета")
Процедура ЗаполнитьПоказателиОтчета()
    
    // ... часть оригинального кода процедуры ...
    
    #Удаление
    бла-бла-бла = Выборка.ЗначениеПоказателя;
    #КонецУдаления
    
    #Вставка
    бла-бла-бла = Выборка.ЗначениеПоказателя + МояДобавка;
    #КонецВставки
    
    // ... продолжение оригинального кода процедуры ...
    
КонецПроцедуры

В чем ключевое преимущество такого подхода?

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

Дополнительные лучшие практики разработки для упрощения обновлений

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

1. Вынос сложной логики во внешние общие модули

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

Вместо написания 50 строк кода внутри типового отчета сделайте так:


//++ Ivanov_AA 15.10.2026 Task_98765
// Было:
// бла-бла-бла = Выборка.ЗначениеПоказателя;
бла-бла-бла = Сво_РасчетПоказателейСервер.ПолучитьСкорректированноеЗначение(Выборка.ЗначениеПоказателя);
//-- Ivanov_AA 15.10.2026

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

2. Правильное размещение комментариев к новым методам

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

3. Использование систем контроля версий (Git)

В крупных командах разработки настоятельно рекомендуется вести разработку с использованием систем контроля версий (например, через 1C:EDT). Это позволяет отслеживать историю изменений каждой строки кода без необходимости загромождать модули бесконечными комментариями «Было»/«Стало» прошлых лет, сохраняя код чистым и легко читаемым.