Рефакторинг кода проекта на 1С-Битрикс

Рефакторинг кода проекта на 1С-Битрикс

Аудит показал: init.php на 3000 строк, SQL-запросы в шаблонах, одинаковый код скопирован в 12 компонентов, а добавление нового поля в каталоге требует правок в 8 местах. Рефакторинг — это превращение этого хаоса в поддерживаемую кодовую базу без изменения внешнего поведения сайта. Ключевое слово — «без изменения поведения»: рефакторинг не должен ломать то, что работает.

Стратегия: не переписывать, а замещать

Полная переписка Битрикс-проекта — ловушка. Бизнес-логика, накопленная годами в шаблонах и обработчиках, не описана в документации. Переписывая с нуля, вы гарантированно потеряете edge cases, которые были пойманы хотфиксами.

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

Приоритеты рефакторинга

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

Приоритет 1: Декомпозиция init.php.

Типичный «плохой» init.php содержит:

• Обработчики событий (AddEventHandler)
• Кастомные функции (хелперы форматирования, генерации URL)
• Классы (иногда несколько в одном файле)
• Прямую инициализацию (подключение к внешним API при каждом хите)

Целевое состояние: init.php содержит только require_once автолоадера и регистрацию обработчиков. Вся логика — в отдельных классах в /local/php_interface/classes/ или /local/modules/.

Структура /local/:

/local/
  php_interface/
    init.php          → автолоадер + регистрация
    classes/
      EventHandlers/  → обработчики событий Битрикс
      Helpers/        → утилиты
      Services/       → бизнес-логика
  modules/
    project.core/     → кастомный модуль проекта
  components/         → кастомные компоненты
  templates/          → шаблоны сайта

Миграция в /local/ — стандартная практика Битрикс. Всё в /local/ имеет приоритет над /bitrix/, что позволяет обновлять ядро без конфликтов.

Приоритет 2: Вынос логики из шаблонов компонентов.

Шаблон компонента (template.php) должен содержать только вывод HTML. Если в нём есть CIBlockElement::GetList(), $DB->Query(), сложные вычисления — это проблема.

Три уровня рефакторинга:

1. result_modifier.php — перенос подготовки данных из template.php. Самый простой шаг, не требует создания нового компонента.
2. class.php — создание класса компонента, наследующего CBitrixComponent. Метод executeComponent() содержит логику, template.php — только вывод.
3. Кастомный компонент в /local/components/project/ — когда стандартный компонент Битрикс перестаёт соответствовать требованиям.

Приоритет 3: Замена прямого SQL на D7 ORM.

Прямые запросы через $DB->Query() — это:

• Отсутствие экранирования (SQL-инъекции)
• Привязка к конкретной СУБД
• Невозможность кэширования через штатный механизм

Замена на \Bitrix\Main\Entity\DataManager или минимально на \Bitrix\Main\DB\Connection::query() с параметризированными запросами. Для инфоблоков — использование \Bitrix\Iblock\Elements\ElementXxxTable (D7 ORM для инфоблоков, доступно с ядра 21.x).

Приоритет 4: Устранение дублирования.

Находите через phpcpd (PHP Copy/Paste Detector) одинаковые блоки кода в разных шаблонах. Типичный паттерн: компонент catalog.section имеет 5 шаблонов с 80% одинакового кода, отличающихся CSS-классами и порядком полей. Решение: один шаблон с параметрами или include-файлы для общих блоков.

Процесс безопасного рефакторинга

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

Типичные ловушки

Рефакторинг без VCS. Удивительно, но значительная часть Битрикс-проектов до сих пор не хранится в Git. Первый шаг рефакторинга — инициализация репозитория с корректным .gitignore (исключить /bitrix/, /upload/, /vendor/, оставить /local/).

Переход на D7 «за один раз». D7 API покрывает не всё. Старый API (CIBlockElement, CSale*) работает и поддерживается. Переводите на D7 только тот код, который рефакторите — не трогайте работающий старый код ради «консистентности».

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

Оценка сроков

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