Стоит ли удалять неиспользуемые процедуры и функции в 1С и как это сделать безопасно?

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей IT и автоматизация бизнеса
← На главную

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

Влияет ли лишний код на производительность системы?

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

  1. Время компиляции модулей: При первом обращении к любому методу модуля платформа 1С компилирует весь модуль целиком. Если модуль раздут тысячами строк лишнего кода, увеличивается потребление оперативной памяти на сервере приложений и возникает микро-задержка при первом открытии формы или вызове функции.
  2. Размер конфигурации и кэша: Большое количество «мусора» увеличивает размер таблицы Config. Это замедляет операции обновления конфигурации базы данных, создание резервных копий и может приводить к раздуванию локального кэша пользователей.
  3. Сложность сопровождения: Это самый критичный фактор. При поиске кода или глобальной замене разработчик вынужден продираться сквозь тысячи строк нерелевантной информации. Кроме того, при обновлении конфигурации через сравнение и объединение, «мертвый» код создает ложные конфликты, на разрешение которых тратится дорогое время программиста.

Проблемы стандартного поиска в Конфигураторе

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

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


// Использование объекта Действие
Кнопка.УстановитьДействие("Нажатие", Новый Действие("ОбработчикНажатияКнопки"));

// Подключение обработчика ожидания
ПодключитьОбработчикОжидания("ВыполнитьПроверкуСтатуса", 60);

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

В-третьих, огромную проблему представляют вызовы через методы Выполнить() и Вычислить(). Если имя процедуры собирается в строковой переменной в зависимости от условий, статический анализатор Конфигуратора никогда не найдет такую связь.

Современные инструменты анализа

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

  1. EDT (Enterprise Development Tools): Эта среда разработки на базе Eclipse обладает гораздо более мощным статическим анализатором. Она строит сложные графы зависимостей и лучше распознает связи между объектами.
  2. BSL Language Server: Популярный open-source инструмент, который часто используется в связке с VS Code. Он позволяет выявлять неиспользуемые переменные и методы с высокой точностью.
  3. SonarQube и специализированные плагины: Позволяют автоматизировать проверку качества кода и находить дубликаты, а также «заброшенные» участки кода.

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

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

Шаг 1: Динамический анализ (Runtime)

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

Другой надежный способ — временное логирование. В подозрительную процедуру можно добавить код записи в Журнал Регистрации:


Процедура СомнительнаяПроцедура() Экспорт
    // Временный код для аудита
    ЗаписьЖурналаРегистрации("АудитКода", УровеньЖурналаРегистрации.Предупреждение, , , "Вызвана СомнительнаяПроцедура");
    
    // Основная логика процедуры
    ...
КонецПроцедуры

Шаг 2: «Мягкое» удаление

Никогда не удаляйте код сразу. Рассмотрим более безопасные методы:


#Если Ложь Тогда
Процедура СтараяПроцедураКоторуюЖалкоУдалить()
    // Текст старого кода
КонецПроцедуры
#КонецЕсли

Рекомендации по ведению разработки

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

Использование расширений: Старайтесь выносить доработки в расширения конфигурации. Это позволит сохранять типовую конфигурацию в чистоте и значительно упростит процесс обновления.

Регулярный рефакторинг: Не оставляйте «хвосты» сразу после того, как функционал стал ненужным. Чистить код по горячим следам гораздо проще, чем пытаться вспомнить назначение процедуры через два года.

Автоматизированное тестирование: Использование инструментов Vanessa-ADD или 1С:Автоматизированное тестирование позволит вам быть уверенными, что удаление очередной «лишней» функции не сломало ключевые бизнес-процессы предприятия.

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

← На главную