Перегруженные общие модули 1С: что показывает Analyzer 1C и как разнести модуль на части

1. Что Analyzer показывает про функции

В режиме «Анализ функций» над таблицей расположен переключатель «Все / Проблемные / Монстры / Расширения». У таблицы десять колонок: «Имя», «Тип», «Модуль», «Строк», «Ветв.», «Вызовы», «Запросов», «В цикле», «КНТ», «Эксп.». По данным API Analyzer (/api/hotspots/functions): «Строк» отражает длину функции, «Ветв.» — число ветвлений, «Вызовы» — исходящие вызовы, «Запросов» — число обращений к таблицам базы. Сортировать список можно по строкам, ветвлениям, исходящим вызовам и запросам.

Колонка «В цикле» в интерфейсе у самых длинных функций показывает значения 1–3, а соответствующее поле API у тех же функций равно нулю. Это разные показатели, и детальное расхождение мы не разбирали. Колонка «КНТ» по фактическим значениям («К» у процедур форм, «С» у серверных функций) указывает на клиентский и серверный контекст выполнения.

Рисунок 1. Таблица анализа функций конфигурации «CG:Управление онлайн торговлей» в Analyzer 1C (фильтр «Монстры», сортировка по числу строк)

2. Самые тяжёлые функции конфигурации

Топ-8 функций по числу строк во всей системе:

Первые шесть позиций — функции выгрузки печатных форм электронных документов, расположенные в модуле одной формы. В этом модуле 86 функций, длиннейшая достигает 1 887 строк, средняя длина составляет 150 строк. Среди общих модулей самая длинная функция лежит в модуле на 119 функций: 1 125 строк при средней длине 47.

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

Рисунок 2. Архитектурный обзор конфигурации: концентрация технического долга в модулях форм ЭДО (до 1887 строк) и общем модуле ядра (1125 строк)

3. Что мы искали и не нашли

В популярных статьях о статическом анализе встречаются метрики, которых в Analyzer 1C 2.7.65 нет в перечне режимов, колонках таблицы функций или метриках API:

• цикломатическая сложность McCabe под явным названием (ближайший аналог — колонка «Ветв.»);
• связность (cohesion) и зацепление (coupling) с нормализованной шкалой от 0 до 1;
• отдельный показатель «обращения к глобальным переменным»;
• глубина вложенности операторов как обособленная метрика.

Мы исследовали штатный состав экранов продукта. Если какая-то из перечисленных метрик присутствует в недокументированных режимах, поделитесь опытом в комментариях.

Числовые пороги вида «модуль свыше 2 000 строк — жёлтая зона, 5 000 — красная» мы намеренно не приводим: у них нет формального источника в стандартах разработки 1С. В исследованной базе отдельные функции превышают 1 000 строк, однако суммарный размер модуля в строках вендором не лимитируется.

4. Что такое «монстр»

Фильтр «Монстры» в интерфейсе присутствует, и визуальная красная метка на функциях проставляется. В руководстве вендора монстром названа функция с сотнями и тысячами вызовов. На наших замерах картина иная: колонка «Вызовы» отражает исходящие вызовы, а признак is_god (по API) установлен у 43 из 300 функций верхнего списка по длине. Алгоритм выставления метки вендором не раскрывается: среди помеченных есть функции от 101 строки, а среди непомеченных встречаются функции до 335 строк. Признак не сводится к одной лишь длине строки. Использовать фильтр как ориентир первоочередных кандидатов на рефакторинг полезно, однако объяснять его читателю простой формулой без консультации с вендором некорректно.

5. Циклические зависимости

Режим «Циклы» показывает кольца модулей по убыванию веса (вес — совокупное число вызовов вдоль кольца), интерактивный граф и перечень «Где разорвать» со слабейшими рёбрами. В нашей системе обнаружено три кольца: 64 модуля (235 рёбер, вес 3 838), 3 модуля (вес 8) и 2 модуля (вес 6). Для архитектора это важный ориентир: крупное кольцо невозможно разорвать одним действием, начинать декомпозицию следует со слабейших связей с весом 1–2.

Рисунок 3. Режим «Циклы» в Analyzer 1C: кольцо из 64 модулей ядра (вес 3838) и таблица слабейших связей для пошаговой развязки

6. План разделения общего модуля

Практический порядок декомпозиции на основе собранных метрик:

1. Инвентаризация функций. Выписать функции перегруженного модуля и сгруппировать их по доменным направлениям: проведение, печатные формы, интеграционный обмен, проверки, расчёты, служебные алгоритмы.
2. Определение границ ответственности. Каждое доменное направление выносится в отдельный общий модуль. Функции, вызывающие друг друга внутри домена, остаются вместе; перекрёстные связи контролируются по графу вызовов.
3. Минимизация интерфейса. Делать экспортными исключительно те процедуры и функции, к которым обращаются внешние потребители. Вспомогательные методы остаются локальными.
4. Пошаговая итерация. Выносить функционал строго по одному направлению, выполняя синтаксический контроль платформы и автоматизированные тесты после каждого шага.
5. Корректные имена модулей. Имя общего модуля не должно содержать точку (см. поведение платформы в разделе 7). Концепция «Область.Назначение» недопустима; корректный стандарт: РаботаСДокументамиПроверки, РаботаСДокументамиПечатныеФормы.

7. Пример: до и после, проверенный платформой

В исходных теоретических примерах нередко встречается вызов вида ТабДок.ВывестиСтроку(Док.Номер). У объекта ТабличныйДокумент такого метода не существует: в рантайме платформа генерирует исключение «Метод объекта не обнаружен (ВывестиСтроку)». Штатная проверка модулей (/CheckModules) ошибку пропускает, так как параметр не типизирован. Синтаксический контроль не гарантирует работоспособности кода.

Проверенный рабочий вариант (до рефакторинга):

1Процедура СформироватьПечатнуюФормуИПроверить(Док, ТабДок) Экспорт
2	// Проверка заполнения
3	Если Не ЗначениеЗаполнено(Док.Контрагент) Тогда
4		ВызватьИсключение "Не указан контрагент";
5	КонецЕсли;
6
7	// Формирование печатной формы
8	ТабДок.Очистить();
9	ТабДок.Область(1, 1).Текст = Док.Номер;
10КонецПроцедуры

После разделения: модуль РаботаСДокументамиПроверки:

1Функция ПроверитьЗаполнениеПередПечатью(Док) Экспорт
2	Результат = Новый Структура("Ошибка, ТекстОшибки", Ложь, "");
3	Если Не ЗначениеЗаполнено(Док.Контрагент) Тогда
4		Результат.Ошибка = Истина;
5		Результат.ТекстОшибки = "Не указан контрагент";
6		Возврат Результат;
7	КонецЕсли;
8	Результат.Ошибка = Ложь;
9	Возврат Результат;
10КонецФункции

и модуль РаботаСДокументамиПечатныеФормы:

1Процедура СформироватьПечатнуюФорму(Док, ТабДок) Экспорт
2	ТабДок.Очистить();
3	ТабДок.Область(1, 1).Текст = Док.Номер;
4КонецПроцедуры

Результаты проверки на платформе 8.3.27.2130: пакетный запуск /CheckModules -ThinClient -Server -ExternalConnection проходит без предупреждений и ошибок. Вызов методов через внешнее COM-соединение с тестовой структурой документа выполняется корректно. Имя модуля с точкой (РаботаСДокументами.Проверки) при пакетной загрузке XML-выгрузки платформа молча пропустила: код возврата 0, диагностических сообщений нет, однако новый модуль в дереве метаданных базы не появился. При разделении модулей через файлы выгрузки именования с точкой недопустимы.

📎 Файл к статье

В прикреплённом архиве — 1c-refactor-analyzer-companion.zip (1 $m):

• РаботаСДокументами_Монолит.bsl — исходный нерефакторенный модуль-монолит с антипаттерном «Божественный объект» (смешение валидации и формирования табличного документа);
• РаботаСДокументамиПроверки.bsl — эталонный модуль проверок по стандартам 1С:ИТС с чистым интерфейсом ПроверитьЗаполнениеПередПечатью(Док);
• РаботаСДокументамиПечатныеФормы.bsl — выделенный модуль вывода печатных форм СформироватьПечатнуюФорму(Док, ТабДок);
• bsl_module_analyzer.py — автономный консольный статический анализатор кода 1С (расчёт LOC, веса ветвлений, выявление циклических зависимостей модулей и расчёт слабейших рёбер для их разрыва);
• test_naming_dot_trap.py — модульные тесты ловушки наименования модулей с точкой (РаботаСДокументами.Проверки) и эмуляция платформенного роутинга 1С;
• verify_companion.py — сквозной проверочный скрипт автоматического аудита всех материалов архива (100% PASS);
• README.md — подробная инструкция по исследованию и применению шаблонов на реальных базах.

Файл прикреплен в верхней части страницы в блоке скачивания материалов.

8. Что не проверено

• Поведение Analyzer 1C на компактных конфигурациях: на одной установке действует ограничение в одну систему.
• Внутренний алгоритм фильтра «Монстры», точная семантика колонки «КНТ» и расхождение колонки «В цикле» со значениями REST API.
• Экран «Граф вызовов» на всей конфигурации (в этой статье детально исследовался экран «Циклы»).
• Штатный экспорт отчётов в форматы Excel или HTML: в проверенных режимах кнопка экспорта не обнаружена.
• Долгосрочный эффект рефакторинга на скорость сопровождения: эмпирические замеры не проводились.
• Метрики типовых конфигураций вендора (ERP, УТ 11, БП 3.0): исследованная конфигурация — отраслевая.

9. Источники

• Карточка решения: Analyzer 1C на Маркетплейсе Infostart (руководство пользователя использовано для верификации названий режимов).
• Метрики и снимки получены на реальном стенде 13.10.2026, скрипты и данные проверки зафиксированы в репозитории проекта.

Обсуждение

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

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 70 публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для платформы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S

Данные замеров сняты на реальном стенде 13.10.2026 с одной конфигурации; результаты отражают метрики исследуемой системы.