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

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

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

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

Когда конфигурации нужен рефакторинг

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

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

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

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

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

Третья группа приёмов — оптимизация работы с данными: замена запросов в циклах на один запрос с соединением или временной таблицей, использование пакетных запросов, замена обхода выборки на выгрузку в таблицу значений с группировкой. Четвёртый приём — переименование: переменные «ТЗ», «Стр», «Рез» получают осмысленные имена «ТаблицаТоваров», «СтрокаДокумента», «РезультатРасчета».

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

Встроенные средства конфигуратора: глобальный поиск по конфигурации (Ctrl+Shift+F) позволяет найти все места использования процедуры или переменной перед её изменением, а поиск ссылок на объект метаданных показывает, где используется справочник или документ. Это минимум, без которого рефакторинг превращается в лотерею.

Для более глубокого анализа применяют EDT (1C:Enterprise Development Tools) — среда подсвечивает неиспользуемые переменные, потенциальные ошибки и проблемные конструкции. Плагин 1C:CodeStyle и проверки на базе 1C:ACC (автоматизированная проверка конфигураций) находят нарушения стандартов разработки: запросы в циклах, обращения к предопределённым элементам, устаревшие методы. Для контроля регрессий полезны инструменты тестирования — Vanessa Automation или TestManager: сценарные тесты фиксируют поведение до рефакторинга и подтверждают, что после него ничего не сломалось.

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

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

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

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

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

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

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

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

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

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

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

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

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

Норма

Движения и итоги совпадают с эталоном

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

Изменились суммы, появились новые движения

Формирование отчётов

Норма

Результат идентичен эталонному

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

Расхождения в итогах или детализации

Время выполнения

Норма

Не хуже, чем до рефакторинга

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

Операция стала медленнее

Внешние интеграции

Норма

Обмены и внешние обработки работают

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

Ошибки вызова процедур, обрывы обмена

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

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

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

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

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

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

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

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

Строго говоря, нет — можно сравнивать результаты вручную по эталонным данным. Но автотесты (Vanessa Automation, TestManager) резко снижают риск пропустить регрессию и окупаются уже на второй-третьей итерации, особенно для расчётных механизмов.

Кто должен проводить рефакторинг — штатный разработчик или подрядчик?

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

Как убедить руководство выделить время на рефакторинг?

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