Рефакторинг кода в 1С: что это такое и как его выполнять

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

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

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

Когда код в 1С требует рефакторинга

Главный признак — стоимость изменений растёт быстрее, чем сложность задач. Если простая правка требует изучения сотен строк кода, а после неё всплывают ошибки в неожиданных местах, код накопил «технический долг». Другие типичные симптомы: один и тот же фрагмент скопирован в пять объектов, процедуры длиннее экрана, переменные с именами вроде ТЗ2 и Флаг3, запросы внутри циклов обхода выборки.

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

Чем рефакторинг отличается от доработки и оптимизации

Эти три задачи часто смешивают, но у них разные цели и критерии приёмки. Рефакторинг не меняет поведение — проверяется тем, что результаты работы до и после совпадают. Доработка меняет функциональность — проверяется соответствием новым требованиям. Оптимизация меняет скорость или потребление ресурсов — проверяется замерами.

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

Типовые приёмы рефакторинга в 1С

Самый частый приём — вынос повторяющегося кода в общий модуль. Если расчёт скидки или формирование номера документа скопирован в пять мест, создаётся функция в общем модуле, а все вызовы заменяются обращением к ней. Важно сразу правильно выбрать флаги модуля: серверный ли он, нужен ли вызов сервера, привилегированный режим.

Второй приём — устранение запросов в цикле. Вместо обращения к базе на каждой итерации данные выбираются одним запросом с соединением или помещаются во временную таблицу. Это одновременно и рефакторинг, и оптимизация: структура кода упрощается, а нагрузка на СУБД падает в разы.

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

// Было: запрос в цикле
Для Каждого Строка Из Товары Цикл
    Запрос.УстановитьПараметр("Номенклатура", Строка.Номенклатура);
    Остаток = Запрос.Выполнить().Выгрузить();
КонецЦикла;

// Стало: один запрос по всей таблице
Запрос.УстановитьПараметр("Товары", Товары.Выгрузить());
Остатки = Запрос.Выполнить().Выгрузить();

Пошаговый порядок безопасного рефакторинга

Рефакторинг начинается не с правки кода, а с подготовки: копия базы, актуальная выгрузка в хранилище или git, зафиксированное эталонное поведение. Без эталона невозможно доказать, что поведение не изменилось, — а это главное требование к рефакторингу.

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

1. 1
   Сделайте копию рабочей базы и зафиксируйте текущее состояние в хранилище конфигурации
2. 2
   Сформируйте эталон: результаты ключевых отчётов, проведение типовых документов, выгрузки обменов
3. 3
   Выполните одно атомарное изменение (вынос функции, переименование, замена запроса)
4. 4
   Прогоните эталонный сценарий и сравните результат с эталоном
5. 5
   При совпадении — зафиксируйте изменение, при расхождении — откатите и найдите причину
6. 6
   Повторяйте цикл малыми шагами до завершения плана
7. 7
   Проведите финальное тестирование на копии с данными, близкими к боевым

Специфика 1С: что легко сломать нечаянно

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

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

Как проверить, что поведение не изменилось

Минимальный набор проверок: ключевые отчёты формируются с идентичными итогами, документы проводятся с теми же движениями по регистрам, обмены выгружают те же данные. Для регистров удобно сравнивать таблицы движений до и после на одном и том же наборе документов.

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

Типичные ошибки при рефакторинге

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

FAQ: частые вопросы о рефакторинге в 1С