Рефакторинг 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 и серверными логами. Ошибки могут проявляться не сразу, а при определённых условиях: конкретный тип товара, определённая группа пользователей, специфичный браузер.

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

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

Аудит сайта Битрикс: найти проблемы, пока они не нашли вас

Представьте: вы открываете проект от предыдущей команды — в init.php 3000 строк, обработчики OnBeforeIBlockElementUpdate вложены друг в друга, в корне сайта лежит dump.sql на 4 гигабайта, а каталог upload/ весит больше базы. Мы видим такие проекты каждую неделю. И это не исключение — это норма для Битрикса после нескольких лет активной разработки без контроля качества. Аудит сайта на 1С‑Битрикс — единственный способ объективно оценить реальное состояние проекта перед тем, как вкладывать деньги в доработки или масштабирование. Он выявляет узкие места в коде, базе данных, конфигурации сервера и безопасности. А главное — показывает, что исправить чтобы сайт работал быстрее и не падал в пик продаж. Регулярный аудит сайта 1С‑Битрикс окупается за 2–3 месяца: экономия на хостинге достигает 40 000–60 000 рублей в месяц, а время на исправление ошибок сокращается втрое по сравнению с реактивным подходом.

Зачем нужен аудит сайта на Битрикс?

Смена подрядчика — вы берете проект от другой команды и не знаете, какие «мины» оставлены в коде. Обработчики событий в init.php, забытые скрипты, модифицированные файлы ядра — всё это может выстрелить в самый неподходящий момент. Мы однажды нашли в одном проекте 47 обработчиков, из которых 12 были мёртвыми — инфоблоки удалены, а код продолжал дёргать CIBlockElement::GetList() на каждом хите. Несколько лет такой нагрузки — около 12 миллионов лишних запросов к базе.

Падение позиций — за просадкой органики почти всегда стоят технические причины: дубли страниц, сломанный canonical, 50 тысяч мусорных URL в индексе. Аудит покажет, где Google теряет ваш трафик. В одном типичном проекте количество URL с параметрами сортировки достигало 300 000 — каждая комбинация PAGEN_1=2&sort=price попадала в индекс отдельно.

Тормоза под нагрузкой — сайт падает именно в разгар распродажи, когда каждая минута простоя стоит денег. Мы находим причины: неоптимизированные запросы, отсутствие кэша, тяжелые агенты. Например, один запрос к b_iblock_element_property без индекса может добавлять 3–4 секунды к времени генерации страницы.

Подозрение на взлом — спам-рассылки с сервера, редиректы на казино в мобильном трафике, непонятные файлы в /bitrix/modules/. Аудит безопасности выявит бэкдоры и веб-шеллы.

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

Что скрывается в init.php и базе данных?

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

init.php и обработчики событий — главная свалка кода. Там копятся OnAfterUserLogin, OnBeforeOrderAdd, OnAdminContextMenuShow, которые никто не рефакторит годами. В одном проекте мы нашли 47 обработчиков, из них 12 — мёртвые (инфоблоки удалены, но код продолжал дёргать CIBlockElement::GetList() на каждом хите). Аудит вычищает такой балласт и снижает нагрузку на сервер.

Версии и совместимость. Версия ядра — если ниже 22.0, обновление критично (PHP 8.1 не поддерживается). Модули из Маркетплейса часто конфликтуют друг с другом после обновления. Лицензия без активного ключа — нет обновлений безопасности.

Конфигурация сервера. PHP memory_limit < 256M — проблема на каталогах от 10 тысяч товаров. OPcache revalidate_freq = 0 в продакшне — процессор перегружен. MySQL innodb_buffer_pool_size должен занимать 70–80% RAM. На MySQL 8.0+ query_cache удалён, но в старых конфигах остаётся — генерирует ошибки в логах. Отсутствие expires для статики в nginx — каждое обновление страницы загружает JS/CSS заново.

База данных — тут самое интересное. Таблица b_event_log разрастается до гигабайтов без настройки очистки. В одном проекте она занимала 12 ГБ, хотя ежедневно туда писалось 500 000 записей. Таблица b_search_content_text с полнотекстовым индексом может весить больше самого контента. Таблицы от удалённых модулей (b_forum_*, b_learning_*) занимают место и тормозят бэкапы. Включаем slow query log, ждём сутки, анализируем. Один запрос к b_iblock_element_property без индекса может тормозить весь сайт — мы фиксировали задержки до 7 секунд на страницу.

Файловая система. /upload/resize_cache/ — весит 50–100 ГБ, хранит ресайзы давно удалённых картинок. Бэкапы в корне — backup_old.tar.gz рядом с index.php, доступен по прямой ссылке. Файлы ядра, изменённые вручную, перезапишутся при обновлении, и кастомная логика молча пропадёт.

Как SEO-аудит убирает дубли и мусор из индекса?

Параметры фильтров и сортировок генерируют тысячи URL: /catalog/?PAGEN_1=2, /catalog/?sort=price&order=asc — каждый в индексе как отдельная страница. Модуль SEO Битрикс умеет ставить canonical, но по умолчанию не делает это для параметризованных URL. Стандартный robots.txt закрывает /bitrix/, но не закрывает /search/, /personal/, /ajax/ — там ещё тысячи мусорных страниц. Генератор sitemap.xml Битрикса иногда включает неактивные элементы и 404-страницы. Без структурированных данных Schema.org (Product, BreadcrumbList, Organization) сниппеты в выдаче скучные. Core Web Vitals: LCP > 2.5 с на мобильных — обычное дело для неоптимизированного Битрикса; виноваты неоптимизированные изображения и блокирующий JS. В среднем после аудита мы сокращаем индекс на 60–80 % — удаляем дубли, настраиваем canonical и правильные noindex. Закажите SEO-аудит, чтобы ваш сайт начал получать трафик с тех запросов, которые теряете сейчас.

Зачем проверять безопасность Битрикса?

SQL-инъекции через $_REQUEST в кастомных компонентах — предыдущие разработчики не всегда используют $DB->ForSql(). XSS при выводе пользовательского ввода без htmlspecialcharsbx(). Кастомные формы загрузки файлов, не проверяющие MIME-тип и расширение — загрузил .php как «картинку» и получил веб-шелл. Типичные находки: отключённый модуль «Проактивная защита» (WAF не работает, журнал вторжений пуст), админка без ограничения по IP (/bitrix/admin/ открыта всему миру), adminer.php или phpMyAdmin в корне — забыли удалить после миграции, обфусцированный код в .htaccess с редиректом мобильного трафика через RewriteCond %{HTTP_USER_AGENT}, модифицированные файлы ядра с вставками eval(base64_decode(...)). В одном проекте мы нашли 23 таких файла — сайт месяцами раздавал спамное содержимое через протокол AMP. Подробнее можно почитать про SQL-инъекции и межсайтовый скриптинг. Свяжитесь с нами для проверки безопасности вашего проекта — мы обнаружим уязвимости, которые не видят сканеры.

Как мы повышаем производительность?

Профилируем через Blackfire или Tideways — видим, какие функции потребляют CPU. Частый кандидат — CIBlockElement::GetList() в цикле (классический N+1). Смотрим hit rate OPcache, Memcached, управляемого кэша Битрикс. Если кэш композитного сайта инвалидируется при каждом заказе, он бесполезен — однажды мы сократили число инвалидаций с 80% до 2% за счёт правильной настройки тегов. Агенты Битрикс — если agents_use_crontab не включён, они выполняются на хитах пользователей; тяжёлый агент = тормоз для случайного посетителя. Нагрузочное тестирование: базовый RPS, деградация при 2× и 5× нагрузке, поведение при превышении лимита (корректная деградация или 502 Bad Gateway?). На одном проекте мы выявили, что пиковый RPS упирался в 12, а после оптимизации стал 150 — рост в 12,5 раз.

Что ищем в коде?

Оцениваем кастомные разработки предыдущих команд: используют ли D7 ORM или лепят $DB->Query() в обход всего. PSR-12, автозагрузка, структура модулей — или всё в одном файле. N+1 — GetList() внутри while($arItem = $rsItems->Fetch()) — классика. Модифицированные файлы ядра (bitrix/modules/sale/lib/) с ручными правками — при обновлении всё сломается. «Временные» решения, которые живут третий год — // TODO: переделать от позапрошлого года. В среднем на один проект мы находим 15–25 проблем в коде, половина из них — с потенциальной потерей данных.

Формат отчёта

Каждая проблема описывается по схеме: что нашли → где → как влияет → как исправить → трудоёмкость. Отчёт отдаём в формате PDF и Google Docs для совместной работы. Пять признаков, что сайту на Битриксе нужен аудит: init.php разросся более чем на 2000 строк; база данных превысила 5 ГБ, а таблица b_event_log — 1 ГБ; страницы загружаются дольше 3 секунд на мобильных; в Search Console десятки тысяч страниц в индексе с ошибками; вы нашли файлы с подозрительным содержимым в /bitrix/modules/. Если хотя бы один пункт совпадает — пора заказывать аудит.

Как мы проводим аудит?

1. Доступы — панель Битрикс, SSH, база, Яндекс.Вебмастер, Search Console.
2. Автоматика — «Монитор качества» Битрикс, Screaming Frog, GTmetrix, сканеры безопасности. Ловят 60% проблем.
3. Ручной анализ — остальные 40%. Архитектура, код, бизнес-логика, конфигурация — это только руками. Каждый аудит ведёт senior-разработчик с 10+ годами опыта.
4. Отчёт с приоритетами.
5. Обсуждение — встреча с вами, ответы на вопросы, согласование плана устранения.

Среднее время полного цикла — 5 рабочих дней для технического аудита, до 3 недель для комплексного. Гарантируем конфиденциальность результатов и сохранность ваших данных.

Что входит в deliverables?

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

Виды аудита и сроки

Мы провели 50+ аудитов проектов на Битрикс — от интернет-магазинов до корпоративных порталов. Наш опыт показывает: в среднем аудит окупается в течение 2–3 месяцев за счёт снижения расходов на хостинг (до 40 000–60 000 ₽ в месяц) и сокращения времени на исправление ошибок (в 3 раза быстрее, чем при реактивном подходе). Документация 1С-Битрикс подтверждает, что регулярный аудит — лучший способ продлить жизнь проекту.

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