Что такое рефакторинг в 1С и как его применять

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

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

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

Зачем нужен рефакторинг и когда он окупается

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

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

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

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

Базовый приём — выделение метода: фрагмент кода, решающий отдельную задачу, переносится в собственную функцию с говорящим именем. Вместо ста строк расчёта внутри обработчика проведения появляется вызов РассчитатьСуммуДокумента(ТаблицаТоваров), и читатель сразу понимает смысл, а детали при необходимости смотрит внутри функции.

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

Третья группа приёмов касается запросов. Замена выборки всех полей на список нужных, перенос фильтрации из цикла по выборке в условие запроса, использование временных таблиц вместо вложенных подзапросов — всё это делает код и быстрее, и понятнее. Для сложных запросов полезно включить консоль запросов и сравнить план выполнения до и после изменений.

Отдельная тема — переименование. Процедуры вида Обработка1() и переменные ТЗ2 превращаются в ЗаполнитьДанныеОтгрузки() и ТаблицаОстатков. В конфигураторе переименование метаданных выполняется безопасно благодаря автоматическому обновлению ссылок, а вот переименование процедур в модулях требует аккуратного поиска всех вызовов.

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

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

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

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

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

Рефакторинг метаданных: что можно и что нельзя трогать

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

Безопасные операции — переименование объектов и реквизитов (платформа обновит ссылки в коде, а данные сохранятся), изменение синонимов, перераспределение процедур по модулям. Опасные — изменение типа реквизита (например, с строки на ссылку), удаление реквизитов, изменение длины строки в меньшую сторону: при обновлении конфигурации базы данные могут быть потеряны или усечены.

Если требуется устранить дублирующиеся справочники (классическая ситуация: «Контрагенты» и отдельный «Партнёры», введённый когда-то для обхода ограничения), планируйте это как отдельный проект: обработка переноса данных, замена ссылок в документах, период параллельной работы и только потом удаление старого объекта.

Инструменты, которые помогают в рефакторинге

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

Для более глубокого анализа применяют 1C:EDT с плагинами проверки кода (например, на базе EDT-валидации или сторонних инструментов статического анализа): они автоматически находят неиспользуемые переменные, потенциальные обращения к неопределённым значениям, запросы в циклах и нарушения стандартов разработки. Это позволяет составить план рефакторинга по фактам, а не по ощущениям.

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

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

Частые ошибки при рефакторинге

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

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

Третья группа ошибок — технические: изменение экспортных процедур, которые вызываются из внешних обработок и расширений, без проверки этих вызовов; перенос кода в общий модуль с неправильными флагами (клиент/сервер), из-за чего вызовы начинают падать; забытый полнотекстовый поиск по конфигурации после переименования процедуры.

Как проверить, что рефакторинг прошёл успешно

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

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

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

Контрольные точки

Как проверить результат

Результаты отчётов и расчётов

Норма

Суммы и остатки совпадают с эталоном до копейки

Тревожный признак

Есть расхождения, пусть и небольшие

Проведение документов

Норма

Все типы документов проводятся и отменяют проведение без ошибок

Тревожный признак

Ошибки на граничных случаях: пустые таблицы, большие объёмы

Расширения и внешние обработки

Норма

Применяются и работают как раньше

Тревожный признак

Ошибки вызова переименованных или перенесённых процедур

Режимы запуска

Норма

Работает в тонком, толстом и веб-клиенте

Тревожный признак

Ошибки вызова серверных процедур из клиентского контекста

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

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

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

Нужно ли согласовывать рефакторинг с заказчиком, если результат не меняется?

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

Можно ли рефакторить типовую конфигурацию без снятия с поддержки?

Изменение типового кода усложняет обновления. Безопасный путь — выносить свою логику в расширения конфигурации и внешние обработки, а типовые модули не трогать. Если доработки в типовом коде уже есть, рефакторинг как раз помогает постепенно перенести их в расширение и вернуть конфигурацию на полную поддержку.

С чего начать рефакторинг большой старой конфигурации?

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

Сколько времени должна занимать проверка после рефакторинга?

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

Помогает ли рефакторинг при переходе на новую платформу или EDT?

Да, и это удачный момент для него. Перед миграцией на 1C:EDT полезно устранить явные ошибки, которые найдёт статический анализ, — неиспользуемые переменные, обращения к несуществующим реквизитам, запросы в циклах. Конфигурация после такой чистки проходит проверки EDT быстрее, а список реальных проблем становится короче и понятнее.