Как убрать ложные изменения форм и очистить неиспользуемый код при обновлении нетиповых конфигураций 1С?

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

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

Часть 1: Ложные изменения форм и справочной информации

Проанализируем ситуацию, когда абсолютно чистые, нетронутые формы документов или разделы справки при обновлении помечаются платформой как измененные с обеих сторон. Это происходит из-за особенностей хранения и рендеринга метаданных в платформе 1С:Предприятие.

Почему это происходит со справочной информацией?

Справка в 1С хранится во внутреннем формате HTML. При открытии и сохранении объектов платформа задействует системный движок рендеринга (в старых версиях это был MSHTML/Internet Explorer, в новых — WebKit/Chromium). Даже если вы не меняли текст справки, платформа может автоматически обновить служебные метатеги в заголовке HTML-документа, например:

<meta name="generator" content="MSHTML 11.00...">

Из-за различий в версиях операционной системы или установленного браузера на компьютерах разработчика поставщика и конечного программиста XML-код справки незначительно меняется. Платформа видит изменение строки метатега и считает справочную информацию модифицированной.

Почему это происходит с управляемыми и обычными формами?

Любая форма 1С — это сложная XML-структура. Помимо видимых элементов интерфейса, в ней хранятся внутренние уникальные идентификаторы (UUID), точные координаты привязок элементов (для обычных форм), настройки порядка обхода реквизитов, а также языковые ресурсы. При изменении версии платформы формат записи этой XML-структуры может автоматически оптимизироваться. Если объект снят с замка (находится в режиме «Редактируется с сохранением поддержки»), любое микроскопическое расхождение в структуре XML-файла формы распознается как локальное изменение.

Как решить проблему ложных изменений форм и справки?

Рассмотрим по шагам основные способы борьбы с этим явлением.

1. Возврат объектов на строгую поддержку («Замок»)

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

   • Откроем конфигуратор вашей базы данных.
   • Перейдем в меню Конфигурация — Поддержка — Настройка поддержки.
   • В открывшемся дереве метаданных найдем нужный объект (например, документ, у которого ложно меняется форма).
   • Дважды кликнем по объекту и в появившемся окне установим правило: «Объект поставщика не редактируется».
   • Сохраним изменения и обновим конфигурацию базы данных.

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

2. Правильная технология обновления конфигурации

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

   • Перейдите в меню Конфигурация — Поддержка — Обновить конфигурацию.
   • Выберите файл обновления (.cfu или основной .cf новой версии поставщика).
   • В открывшемся окне сравнения и объединения примените фильтр «Показывать только дважды измененные».
   • Для всех ложно измененных форм и разделов справки явно установите режим объединения: «Взять из новой конфигурации поставщика». Это перезапишет локальную некорректную XML-структуру чистым кодом от разработчика конфигурации.
3. Очистка кэша конфигуратора

   Иногда устаревшие метаданные кэшируются платформой локально на рабочем месте разработчика. Для устранения системного сбоя рекомендуется выполнить полную очистку кэша. Самый надежный способ — удалить базу из списка запуска 1С и добавить её заново (при этом папка с кэшем пересоздается автоматически).

Часть 2: Очистка конфигурации от старого и неиспользуемого кода

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

Почему стандартная проверка АПК (правило 2.5.9) не находит эти процедуры?

Инструмент «1С:Автоматизированная проверка конфигураций» (АПК) содержит правило 2.5.9, контролирующее отсутствие неиспользуемых методов. Однако стандартные алгоритмы статического анализа АПК успешно находят только неэкспортные (локальные) процедуры и функции в пределах одного модуля.

Если процедура объявлена с ключевым словом Экспорт, анализатор не может гарантировать, что этот метод не вызывается динамически. Посмотрим на классический пример такого кода:

// Данный метод является экспортным в общем модуле "РаботаСКлиентами"
Процедура ПересчитатьСкидкуПокупателя(Клиент) Экспорт
    // Этот код устарел и больше не используется в конфигурации.
    // Но из-за ключевого слова "Экспорт" стандартный АПК считает его активным.
    ПровестиКалькуляцию(Клиент);
КонецПроцедуры

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

Инструменты для глубокого поиска и очистки «мертвого» кода

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

1. Использование 1С:Enterprise Development Tools (EDT)

   Современная среда разработки EDT, построенная на платформе Eclipse, обладает значительно более продвинутым механизмом статического анализа кода по сравнению со стандартным Конфигуратором 1С. EDT строит так называемый граф вызовов (Call Graph) для всей конфигурации.

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

2. Связка SonarQube + BSL Language Server

   Для крупных проектов и командной разработки стандартом де-факто является использование платформы непрерывного анализа качества кода SonarQube совместно с плагином BSL Language Server. В правилах анализатора BSL LS существуют специализированные проверки, способные находить неиспользуемые публичные (экспортные) методы в общих модулях и модулях менеджеров.

3. Выгрузка конфигурации в текстовые файлы и глобальный поиск

   Если специализированные тяжелые инструменты недоступны, разберем простой и надежный полуавтоматический метод с использованием любого современного текстового редактора (например, Visual Studio Code).

   • В Конфигураторе выберите пункт меню Конфигурация — Выгрузить конфигурацию в файлы... и укажите пустую папку на диске.
   • Откройте полученную папку с исходными кодами в текстовом редакторе VS Code.
   • Используя регулярные выражения в глобальном поиске по папке, выгрузите список всех объявлений экспортных процедур. Например, регулярное выражение для поиска объявлений методов выглядит так: (?i)процедура\s+([a-zA-Z0-9_]+)\s*\(.*?\)\s*Экспорт
   • Затем для каждого найденного имени метода выполните глобальный поиск по всей папке проекта. Если имя процедуры встречается только один раз (в месте своего объявления), данный метод является кандидатом на удаление.

Важное предупреждение: Перед удалением любых процедур и функций, особенно экспортных, всегда проводите полное тестирование конфигурации. Убедитесь, что данные методы не вызываются во внешних обработках, печатных формах или через механизмы интеграции (HTTP/REST/SOAP Web-сервисы), которые могут быть не видны при поиске внутри основной конфигурации.