Разработка и Конфигурация · 10 мин
Рефакторинг в 1С: как пользоваться на практике
Что такое рефакторинг в 1С, когда он нужен, как выполнять его пошагово в конфигураторе, какие инструменты использовать и как проверить, что ничего не сломалось.
Рефакторинг в 1С — это изменение внутренней структуры кода конфигурации без изменения его внешнего поведения: переименование процедур, вынос повторяющихся фрагментов в общие модули, упрощение запросов и условий. Цель — сделать код читаемым, поддерживаемым и менее подверженным ошибкам при дальнейших доработках.
От обычной доработки рефакторинг отличается тем, что пользователи после него не должны заметить никакой разницы: документы проводятся так же, отчёты выдают те же цифры, печатные формы не меняются. Если поведение изменилось — это уже не рефакторинг, а изменение функциональности, и тестировать его нужно по-другому.
На практике рефакторинг чаще всего нужен в трёх ситуациях: конфигурация сильно доработана разными программистами и код стал запутанным; один и тот же фрагмент кода скопирован в десятки мест и любое исправление приходится вносить многократно; типовой код устарел и мешает обновлению. Ниже разберём, как выполнять рефакторинг безопасно.
Когда рефакторинг оправдан, а когда — нет
Рефакторинг оправдан, если код реально мешает работе: исправление одной ошибки порождает две новые, разобраться в чужом модуле занимает часы, обновление типовой конфигурации превращается в недельный проект из-за переписанных типовых модулей. В этих случаях вложения в наведение порядка окупаются скоростью дальнейших доработок.
Не стоит начинать рефакторинг, если конфигурация стабильно работает и дорабатываться не планируется, если нет копии базы и возможности откатиться, или если никто не сможет проверить результат. Рефакторинг «для красоты» без практической цели — частая причина внезапных сбоев в рабочей базе.
Отдельный случай — подготовка к обновлению типовой конфигурации на поддержке. Здесь рефакторинг состоит в выносе своих доработок из типовых модулей в расширение или отдельные общие модули. Это снижает количество конфликтов при обновлении и является одной из самых полезных разновидностей рефакторинга в 1С.
Как выбрать действие
Подготовка: копия, план и точки проверки
Первое обязательное действие — сделать выгрузку базы (dt) или полную резервную копию СУБД. Рефакторинг затрагивает код, а не данные, но ошибка в коде проведения документа может испортить данные при первом же перепроведении. Копия должна быть проверена на восстановление, а не просто лежать на диске.
Второй шаг — зафиксировать эталонное поведение. Выполните в копии базы ключевые операции и сохраните результаты: проведите типовые документы, сформируйте основные отчёты за один и тот же период, распечатайте важные формы. Эти результаты станут эталоном: после рефакторинга те же операции должны дать те же цифры.
Третий шаг — составить список конкретных изменений. Плохая формулировка: «причесать модуль документа». Хорошая: «вынести расчёт скидки из трёх процедур в общий модуль РасчетЦен, переименовать процедуру Обр1 в РассчитатьСкидкуПоКарте». Конкретный список позволяет выполнять работу по шагам и откатывать отдельные пункты.
Основные приёмы рефакторинга в конфигураторе
Переименование процедур, функций и переменных
Имена вида «Процедура1», «Обр», «Таб» затрудняют чтение кода. Переименовывайте через контекстный поиск: найдите все обращения к процедуре через «Поиск ссылок в объекте» или глобальный поиск по имени, затем замените имя во всех местах вызова. Пропущенный вызов даст ошибку при обращении, поэтому после переименования обязательна проверка конфигурации.
Помните про неочевидные места вызова: имена процедур могут встречаться в строках (например, в обработчиках ожидания, в настройках динамических списков, в подключаемых командах). Текстовый поиск по старому имени по всей конфигурации помогает найти такие случаи.
Вынос дублирующегося кода в общие модули
Если одинаковый фрагмент встречается в нескольких объектах, создайте функцию в общем модуле и замените копии вызовом. Функция должна возвращать значение, а не менять глобальное состояние, — так её легче проверять. Общий модуль для серверных расчётов помечайте флагами «Сервер» и «Вызов сервера», для клиентских — «Клиент (управляемое приложение)».
Разбиение длинных процедур
Процедура на несколько экранов, которая проверяет условия, считает суммы, пишет в регистры и формирует сообщения, должна быть разбита на части с говорящими именами: ПроверитьЗаполнение, РассчитатьСуммы, СформироватьДвижения. Каждая часть решает одну задачу, и ошибку локализовать становится проще.
- 1Сделайте выгрузку базы и проверьте, что она восстанавливается
- 2Зафиксируйте эталонные результаты: отчёты, проведение документов, печатные формы
- 3Выполните одно изменение из списка — только одно
- 4Запустите проверку конфигурации (Конфигурация → Проверка конфигурации)
- 5Прогоните эталонные операции и сравните результаты с исходными
- 6Если всё совпало — переходите к следующему шагу, если нет — откатите изменение
Инструменты, которые упрощают работу
Встроенная проверка конфигурации (меню «Конфигурация → Проверка конфигурации») — первый фильтр ошибок: она находит обращения к несуществующим процедурам, синтаксические ошибки и проблемы модулей. Включайте проверку логической целостности и поиск некорректных ссылок.
Глобальный поиск (Ctrl+Shift+F) по всей конфигурации незаменим при переименованиях и переносе кода: он показывает все вхождения имени, включая строковые литералы. Замена через глобальный поиск надёжнее ручного просмотра модулей.
Для более глубокого анализа используются внешние инструменты: EDT (среда разработки от вендора) с встроенными проверками кода и автоформатированием, а также плагины проверки по стандартам разработки. Они находят неиспользуемые переменные, избыточные обращения к базе в циклах, нарушения стандартов оформления. Однако автоматические замечания — это подсказки, а не команды: каждое исправление нужно оценивать на влияние на поведение.
Как проверить, что ничего не сломалось
Проверка делится на три уровня. Первый — синтаксический: проверка конфигурации проходит без ошибок. Второй — функциональный: эталонные операции дают те же результаты. Третий — нагрузочный и пользовательский: в копии базы под тестовыми учётными записями выполняются реальные сценарии работы, включая редкие (сторнирование, корректировки, закрытие периода).
Особое внимание уделите местам, где код вызывается косвенно: подписки на события, регламентные задания, обмены данными, внешние печатные формы. Именно там всплывают ошибки, которых не видно при ручной проверке основных документов. Регламентные задания в тестовой копии стоит запустить принудительно и посмотреть журнал регистрации.
Журнал регистрации — ваш главный помощник после переноса изменений в рабочую базу. В первые дни после обновления просматривайте ошибки ежедневно: многие проблемы проявляются только на реальных данных и реальных правах пользователей.
Как проверить результат
Нет ошибок, только допустимые предупреждения
Ошибки обращения к процедурам или несуществующим объектам
Цифры до и после рефакторинга совпадают
Расхождения в суммах или количестве строк
Документы проводятся, движения по регистрам идентичны
Ошибки проведения или другой набор записей в регистрах
Нет новых ошибок от пользователей и регламентных заданий
Ошибки вызова процедур, прав доступа, обменов
Типичные ошибки и ограничения
Самая частая ошибка — рефакторинг большими кусками: программист переписывает половину модуля за один раз, и при появлении ошибки невозможно понять, какое именно изменение её вызвало. Правило простое: один приём рефакторинга — одна проверка.
Вторая ошибка — изменение поведения «попутно»: вместе с переименованием программист исправляет логику расчёта. После этого сравнение с эталоном бессмысленно, а граница между рефакторингом и доработкой стёрта. Исправления логики делайте отдельной задачей и отдельным тестированием.
Третья ошибка — игнорирование строковых вызовов и внешних потребителей кода. Обработчики ожидания, команды, заданные строкой, внешние обработки, обращающиеся к общим модулям через Выполнить или Вычислить, не находятся автоматической проверкой ссылок. Их нужно искать текстовым поиском.
FAQ
Чем рефакторинг отличается от доработки конфигурации?
Рефакторинг меняет только структуру кода, сохраняя поведение: те же отчёты, те же движения документов, те же печатные формы. Доработка меняет поведение — добавляет новые возможности или исправляет логику. Смешивать их в одном изменении нельзя: проверить корректность становится невозможно.
Можно ли делать рефакторинг типовой конфигурации на поддержке?
Можно, но правильная цель — не «улучшить» типовой код, а вынести свои доработки из типовых модулей в расширение или свои общие модули. Изменение самого типового кода увеличивает количество конфликтов при каждом обновлении и обычно не окупается.
Сколько времени занимает рефакторинг?
Зависит от объёма: переименование процедуры с заменой вызовов — минуты, вынос дублирующегося кода из десятка объектов — часы с проверками, приведение в порядок сильно переписанной конфигурации — недели. Планируйте рефакторинг как отдельную задачу с этапами, а не как фоновую активность.
Что делать, если после рефакторинга отчёт показывает другие цифры?
Откатите последнее изменение и проверьте снова: если цифры совпали, причина в нём. Чаще всего причина — случайно изменённое условие, порядок строк в запросе, потерянное округление или перенос кода с клиента на сервер с другим поведением. Сравните старую и новую версии фрагмента построчно.
Нужно ли согласовывать рефакторинг с пользователями?
Информировать нужно обязательно: на время обновления рабочей базы потребуется завершение сеансов, а в первые дни пользователи должны знать, кому сообщать о странном поведении. Но функциональных изменений они ждать не должны — если поведение изменилось, это ошибка рефакторинга.
Что важно запомнить
Рефакторинг в 1С — это малые проверяемые шаги: копия базы, эталонные результаты, одно изменение за раз, проверка конфигурации и сравнение поведения после каждого шага. Главные приёмы — переименование с полным поиском ссылок, вынос дублей в общие модули, разбиение длинных процедур и перенос доработок в расширение. Не смешивайте рефакторинг с изменением логики и не работайте без возможности отката.