Рефакторинг в 1С: что это и как проводить без риска

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

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

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

Когда рефакторинг действительно нужен

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

К таким признакам относятся: процедуры и функции длиннее одного экрана с несколькими уровнями вложенности условий; одинаковые фрагменты кода, скопированные в несколько объектов; имена переменных вроде «Таб», «Стр1», «Рез2»; обращения к данным через точку вместо запросов; закомментированные блоки неизвестного назначения; модули, где смешаны разные задачи — например, расчёт цен и формирование печатных форм в одном месте.

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

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

Выделение процедур и функций

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

Устранение дублирования через общие модули

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

Переименование и замена магических значений

Переменные и процедуры получают имена, отражающие смысл: вместо «Сумма1» — «СуммаБезНДС». Числа и строки, разбросанные по коду (ставки, коды операций, значения статусов), заменяют на обращения к перечислениям, предопределённым элементам или функциям, возвращающим значение. Это уменьшает количество ошибок при изменении бизнес-правил.

Упрощение запросов и работы с данными

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

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

Как подготовиться: копия, тесты, объём работ

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

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

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

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

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

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

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

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

Типичные ошибки и риски

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

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

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

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

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

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

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

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

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

Проверка конфигурации

Норма

Нет новых ошибок и предупреждений

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

Ошибки в модулях, не найденные методы

Контрольные отчёты

Норма

Цифры совпадают с эталоном до рефакторинга

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

Любые расхождения в суммах и остатках

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

Норма

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

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

Ошибки проведения или другие движения

Производительность

Норма

Время операций не выросло

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

Заметное замедление типовых операций

Рефакторинг или переписывание: как выбрать

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

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

Рефакторинг или переписывание

Рефакторинг

Код работает корректно, но труден для изменений. Низкий риск, результат проверяется сравнением отчётов

Переписывание

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

Отказ от изменений

Код редко меняется и стабилен. Любое вмешательство создаёт риск без выгоды

Часто задаваемые вопросы

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

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

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

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

Нужны ли автотесты для рефакторинга?

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

Чем опасно переименование процедур в общих модулях?

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

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

Ориентир — не более 10–20% времени от сопутствующей доработки, если рефакторинг делается «по пути». Отдельные крупные работы оценивают как самостоятельную задачу с обязательным временем на тестирование, которое обычно сопоставимо со временем самих изменений.

Можно ли откатить рефакторинг, если что-то пошло не так?

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