Рефакторинг 1С-Битрикс: убираем технический долг без простоя

Чистый код для 1С-Битрикс: рефакторинг без риска

Типичный сценарий: init.php разросся до 3000 строк, прямые SQL-запросы в template.php замедляют страницы, одинаковый код скопирован в 12 компонентов. Добавление нового поля в каталоге требует правок в 8 местах. Это технический долг, который снижает скорость разработки и увеличивает стоимость поддержки. Мы проводим рефакторинг без изменения внешнего поведения, чтобы сайт продолжал работать так же, но код стал чистым и поддерживаемым. Наша команда имеет 10+ лет опыта в разработке на 1С-Битрикс и более 50 успешных проектов по рефакторингу.

Технический долг — это метафора, описывающая дополнительные затраты на поддержку кода, вызванные быстрыми, но неоптимальными решениями. В Битрикс-проектах он накапливается особенно быстро из-за обилия интеграций и кастомной логики. Экономия бюджета на поддержку достигает 60% — в среднем это от $5,000 до $15,000 в год для типового проекта. Для крупных проектов экономия может превышать $20,000 в год.

Почему рефакторинг выгоднее полной переписки?

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

Какие участки кода нужно рефакторить в первую очередь?

Приоритет 1 — декомпозиция init.php. Типичный «плохой» init.php содержит обработчики событий, кастомные функции, классы и прямую инициализацию. Целевое состояние: 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–3 месяца за счёт сокращения времени на доработки.

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

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

Приоритет 3 — замена прямого SQL на D7 ORM. Прямые запросы через $DB->Query() — это отсутствие экранирования, привязка к СУБД и невозможность кэширования. Замена на D7 ORM или параметризированные запросы. Согласно официальной документации 1С-Битрикс, D7 ORM позволяет выполнять выборки с автоматическим кэшированием и защитой от SQL-инъекций.

Приоритет 4 — устранение дублирования. Находите через phpcpd одинаковые блоки кода в разных шаблонах. Типичный паттерн: компонент catalog.section имеет 5 шаблонов с 80% одинакового кода, отличающихся CSS-классами. Решение: один шаблон с параметрами или include-файлы.

Как провести рефакторинг без простоев?

1. Фиксация — создайте бэкап и коммит текущего состояния в git.
2. Тестирование — напишите smoke-тесты на критичные страницы (HTTP-статусы, наличие ключевых элементов).
3. Замещение — перенесите один блок логики в класс и подключите его, проверяя тесты.
4. Удаление — удалите старый код после подтверждения, что тесты проходят.
5. Деплой — выкатите на продакшн и мониторьте ошибки 24 часа.

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

• Рефакторинг без VCS. Удивительно, но значительная часть Битрикс-проектов до сих пор не хранится в Git. Первый шаг рефакторинга — инициализация репозитория с корректным .gitignore (исключить /bitrix/, /upload/, /vendor/, оставить /local/).
• Переход на D7 «за один раз». D7 API покрывает не всё. Старый API (CIBlockElement, CSale*) работает и поддерживается. Переводите на D7 только тот код, который рефакторите — не трогайте работающий старый код ради «консистентности».
• Рефакторинг без мониторинга. После выкатки рефакторинга следите за b_event_log и серверными логами. Ошибки могут проявляться не сразу, а при определённых условиях: конкретный тип товара, определённая группа пользователей, специфичный браузер.

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

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