Аудит легаси-кода в 1С-Битрикс: 10 «красных флагов», которые нужно исправить немедленно 🚀

Что такое «плохой код» в мире Bitrix?

Легаси — это не просто старый код. Это код, который страшно трогать. В контексте Bitrix это часто означает нарушение стандартов вендора, игнорирование D7 и «костыли», которые мешают обновлению платформы. Если ваш сайт «тормозит» при 100 посетителях или падает при обновлении модуля «Главный модуль», пора проводить аудит.

🚩 Флаг №1: SQL-запросы в шаблонах и файлах init.php

Это «классика» плохого кода. Когда разработчик не хочет разбираться в API, он пишет global $DB; $DB->Query(...).

Почему это плохо:

1. Безопасность: Прямые запросы — прямой путь к SQL-инъекциям, если данные не фильтруются.
2. Производительность: Такие запросы не кешируются средствами Bitrix.
3. Хрупкость: Если структура таблиц Bitrix изменится (что бывает редко, но метко), сайт «умрет».

Пример «как делать нельзя»:

Как исправить:
Переходите на ORM D7. Создайте описание сущности (Entity) и используйте getlist(). Если нужно работать со стандартными модулями — используйте их API (например, \Bitrix\Iblock\ElementTable).

🚩 Флаг №2: Отсутствие кеширования в кастомных компонентах

Если вы заходите на страницу, и она грузится 3 секунды, а в дебаг-панели вы видите 500 запросов к БД — у вас проблемы с кешем.

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

Как исправить:
Любая выборка данных должна быть обернута в $cache->startDataCache().

• В компонентах используйте $this->startResultCache().
• Не забывайте про Managed Cache (управляемый кеш), чтобы при изменении товара в админке кеш сбрасывался автоматически.

🚩 Флаг №3: Логика в result_modifier.php или (упаси боже) в template.php

Часто в легаси можно встретить отправку писем, создание заказов или сложные расчеты прямо внутри шаблона вывода.

Почему это плохо:
Нарушается принцип MVC (Model-View-Controller). Шаблон должен только отображать данные. Если в шаблоне есть сложная логика, его невозможно тестировать, и в нем легко запутаться.

Пример исправления:
Всю тяжелую логику выносим в класс-хендлер. В result_modifier.php должны остаться только минимальные преобразования данных для вывода (например, форматирование даты).

🚩 Флаг №4: Использование старых функций CModule::IncludeModule в циклах

Вызов CModule::IncludeModule('iblock') внутри цикла или многократно в коде — это лишние проверки, которые копятся как снежный ком.

Почему это плохо:
Это просто неэффективно. В современном PHP и D7 используется автозагрузка классов.

Как исправить:
Используйте \Bitrix\Main\Loader::includeModule('iblock'); один раз в начале файла или в init.php. А еще лучше — переходите на использование неймспейсов D7, где подключение происходит автоматически при обращении к классу.

🚩 Флаг №5: Прямое редактирование файлов ядра или стандартных компонентов

Вы открываете /bitrix/components/bitrix/catalog/ и видите там правки? Бегите. 🏃‍♂️

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

Как исправить:

1. Никогда не трогайте папку /bitrix/.
2. Копируйте компоненты в свое пространство имен (например, /local/components/my_namespace/).
3. Используйте события (Events) для модификации поведения ядра.

🚩 Флаг №6: «Братская могила» в init.php

Файл init.php на 5000 строк, где намешаны обработчики событий, константы, функции-хелперы и подключение сторонних библиотек.

Почему это плохо:
В этом невозможно ориентироваться. Ошибка в одной строке init.php «ложит» весь сайт (и админку, и фронт).

Как исправить:
Разделяйте!

• Создайте папку /local/php_interface/include/.
• Разбейте логику по файлам: events.php, const.php, lib/.
• Используйте автозагрузку классов через composer или встроенный в Bitrix механизм \Bitrix\Main\Loader::registerAutoLoadClasses.

🚩 Флаг №7: Игнорирование local/ и работа в bitrix/php_interface/

Старый подход диктовал хранить конфиги и логику в /bitrix/php_interface/. Современный стандарт — всё кастомное должно лежать в папке /local/.

Почему это плохо:
Это мешает чистоте проекта и усложняет работу с Git. Папка bitrix/ в идеале должна быть в .gitignore.

Как исправить:
Перенесите шаблоны, компоненты и php_interface в папку /local/. Bitrix приоритетно ищет файлы там.

🚩 Флаг №8: Использование $GLOBALS вместо параметров

В легаси-коде часто данные передаются между компонентами через глобальные переменные. Это делает код непредсказуемым.

Почему это плохо:
Вы никогда не знаете, в какой момент и какой скрипт изменил значение переменной. Это порождает «плавающие» баги, которые невозможно отловить.

Как исправить:
Используйте параметры компонентов ($arParams), передавайте данные через аргументы функций или используйте синглтоны для хранения состояния приложения.

🚩 Флаг №9: Отсутствие обработки ошибок и логирования

Код, который просто «молча» падает или выводит die('Error') — это кошмар администратора.

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

Как исправить:
Используйте try-catch блоки. Настройте логирование через AddMessage2Log или современный Monolog. Ошибки должны писаться в файл, а пользователю должно выводиться красивое сообщение «Что-то пошло не так».

🚩 Флаг №10: Хардкод ID (инфоблоков, групп пользователей, свойств)

if ($arItem['IBLOCK_ID'] == 12) — это приговор при переносе сайта на другой сервер или при восстановлении из бекапа.

Почему это плохо:
ID могут измениться. Код станет невалидным, и вам придется вручную искать все места с цифрой «12» по всему проекту.

Как исправить:
Используйте символьные коды (XML_ID) или константы.
Лучший вариант — создать класс со статическими методами, который по символьному коду возвращает ID и кеширует его.

Заключение: С чего начать? 🛠

Не пытайтесь исправить всё сразу. Это прямой путь к тому, чтобы сломать работающий бизнес.

1. Настройте Git, если его еще нет.
2. Проведите аудит и выпишите все проблемные места.
3. Начните с безопасности (SQL-запросы) и производительности (кеширование).

Помните, что качественный код — это не только отсутствие ошибок, но и удобство его поддержки в будущем. Хороший пример — разделение ответственности. Если каждый обработчик будет лежать на своем месте, ваш Bitrix будет летать! 🚀