Зачем 1С переименовывает функции и реквизиты в новых релизах?

← На главную

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

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

1. Борьба за чистоту кода: почему сокращают имена функций и убирают «Получить»

Основная причина переименования функций из вида ПолучитьНомерДокумента в просто НомерДокумента — это соблюдение внутренних стандартов разработки фирмы «1С» (в частности, требований к самодокументируемости кода и борьбе с избыточностью).

Проанализируем ключевые правила именования методов по стандартам «1С»:

Разделение на действия и свойства. Глаголы в именах (такие как Получить..., Рассчитать..., Заполнить...) зарезервированы для процедур. Процедура выполняет активное действие, изменяет состояние системы или объектов, но не возвращает результат напрямую. Для функций, задача которых — просто вернуть определенное значение, свойство или таблицу, рекомендуется использовать существительные. Соответственно, вызов функции, возвращающей номер документа, должен выглядеть как обращение к свойству: Модуль.НомерДокумента(), а не как команда действия.
Борьба с избыточностью. Слово «Получить» в имени функции является избыточным (плеоназмом). Функция по своей природе создана для того, чтобы «получать» и возвращать данные. Дублировать это действие в имени метода не имеет практического смысла. Сокращение имени делает код более лаконичным и легким для чтения.

Рассмотрим пример рефакторинга кода в соответствии со стандартами. Старый вариант объявления функции выглядел следующим образом:


Функция ПолучитьПараметрыРегистрации(ДокументСсылка) Экспорт
    ПараметрыРегистрации = Новый Структура;
    // Логика заполнения структуры
    Возврат ПараметрыРегистрации;
КонецФункции

После приведения к современным стандартам разработки этот метод приобретает правильный, лаконичный вид:


Функция ПараметрыРегистрации(ДокументСсылка) Экспорт
    Результат = Новый Структура;
    // Логика заполнения структуры
    Возврат Результат;
КонецФункции

2. Безопасное удаление данных: зачем реквизиты переименовывают в «УдалитьИмяРек»

Еще одна частая претензия к разработчикам «1С» — появление в конфигурациях реквизитов, справочников или документов с префиксом Удалить (например, УдалитьОсновнойДоговор). Это не признак забывчивости программистов, а строгое следование стандарту безопасного изменения метаданных конфигурации.

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

Чтобы избежать этой катастрофы, применяется методология трехэтапного безопасного удаления данных:

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

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

3. Жизненный цикл устаревшего кода и нарушение обратной совместимости

Проанализируем ситуацию, описанную в первом сообщении форума: при переходе с ЗУП 3.1.10 на 3.1.14 перестали работать внешние печатные формы (ВПФ) из-за удаления старых методов. Почему это произошло?

Согласно стандартам разработки «1С», полная обратная совместимость гарантируется только внутри одной подредакции БСП (например, внутри линейки релизов 3.1.10). Когда конфигурация переводится на новую подредакцию библиотеки (в данном случае произошел крупный скачок на 3.1.14), официально допускается изменение API с нарушением обратной совместимости (Deprecation).

Процесс вывода устаревших методов из эксплуатации выглядит следующим образом:

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


// Устарела. Следует использовать метод НомерДокумента.
//
Функция ПолучитьНомерДокумента(Документ) Экспорт
    Возврат НомерДокумента(Документ);
КонецФункции

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

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

4. Почему платформенный рефакторинг не спасает внешние файлы?

В платформе 1С:Предприятие реализован мощный механизм автоматического рефакторинга. Если разработчик переименовывает метод общего модуля или реквизит внутри конфигуратора, платформа автоматически находит все упоминания этого имени во всех модулях и изменяет их.

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

5. Практические советы: как защитить свои доработки от изменений в новых релизах

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

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


// Безопасное получение номера документа с поддержкой разных версий API
Попытка
    // Пробуем вызвать по новому стандарту
    Номер = ОбщегоНазначения.НомерДокумента(ДокументСсылка);
Исключение
    Попытка
        // Если новый метод недоступен, пробуем вызвать старый метод конфигурации
        Номер = МодульСлужебный.ПолучитьНомерДокумента(ДокументСсылка);
    Исключение
        // Альтернативный ручной способ получения данных без вызова процедур общего модуля
        Номер = ДокументСсылка.Номер;
    КонецПопытки;
КонецПопытки;

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