Проблема двух ядер: Как не сойти с ума при поддержке Битрикс-проектов в 2026 году

Кризис самоидентификации разработчика

Вы открываете проект. Клиент просит «просто поправить расчет скидки». Вы заходите в local/php_interface/init.php и видите это:

        AddEventHandler("sale", "OnBasketUpdate", "MySuperPuperFunction");

function MySuperPuperFunction($ID, $arFields) {
    global $DB;
    $res = $DB->Query("SELECT * FROM my_custom_table WHERE ID=" . (int)$ID);
    // ... 200 строк процедурного кода с $DB->Query внутри ...
}

    

В этот момент в вашей голове происходит столкновение двух миров. С одной стороны — современные стандарты разработки, PSR, SOLID, DI-контейнеры и чистая архитектура. С другой — суровая реальность проекта, который живет уже 10 лет, и бюджет, которого не хватит даже на базовый рефакторинг.

Это и есть проблема двух ядер: когда вы хотите писать на современном D7, а проект заставляет вас чувствовать себя археологом, раскапывающим слой старых методов $DB->Query.

Почему мы всё еще видим $DB->Query() в 2025?

Казалось бы, D7 вышел в 2012 году. Прошло 13 лет. Почему «старое ядро» всё еще живо?

1. Наследование боли. Проекты передаются от агентства к агентству. Каждый следующий разработчик боится трогать то, что «и так работает», и просто дописывает сверху еще один if.
2. Экономика легаси. Бизнесу не важно, насколько красив ваш код под капотом. Если переписывание модуля на ORM займет 40 часов, а добавление одного global $DB — 15 минут, бизнес выберет второе.
3. Документационный вакуум. Долгое время адекватной документации по D7 практически не существовало — разработчики учились по разбросанным примерам и исходникам ядра. Зачатки вменяемой доки появились только к концу 2025 года, но и там работы ещё непочатый край. Намного проще использовать $DB->Query, который «понятен и описан везде», чем копаться в недокументированных глубинах ORM.
4. Страх перемен. Многие Middle-разработчики привыкли к «старому доброму» подходу. Это понятно, предсказуемо и быстро. Современные абстракции кажутся «лишним усложнением».

Архитектура «Франкенштейна»: Жизнь между двумя ядрами

Битрикс уникален тем, что он позволяет обоим мирам сосуществовать. Вы можете в одном файле использовать $APPLICATION->IncludeComponent (Kernel 1) и тут же получать данные через Bitrix\Main\DI\ServiceLocator (Kernel 2).

Но именно здесь кроется ловушка. Если не иметь четкой стратегии, ваш проект превращается в монстра Франкенштейна. В одной части сайта у вас красивые контроллеры и Service Locator, а в другой — result_modifier.php, в котором происходит прямая запись в базу.

Как не сойти с ума в таких условиях?

1. Правило «Бойскаута»

Оставляйте код чуть чище, чем он был до вас. Не нужно переписывать весь модуль. Но если вы правите метод — выделите логику в небольшой сервис. Если видите global $DB — попробуйте заменить его на Application::getConnection().

2. Изоляция легаси

Не позволяйте старому коду диктовать правила для нового. Если вам нужно внедрить сложную логику в старый компонент — напишите её в современном стиле (в отдельном классе-сервисе), а в компоненте просто вызовите этот сервис.

        // В старом компоненте
$service = \Bitrix\Main\DI\ServiceLocator::getInstance()->get('my.modern.service');
$arResult['DATA'] = $service->calculateSomething($arParams['ID']);

    

3. Используйте Service Locator как мост

Service Locator в Битриксе — это идеальный инструмент для гибридных проектов. Он позволяет внедрять современные зависимости даже туда, где конструктор заблокирован наследованием (например, в классы компонентов или старые обработчики событий).

От спагетти к системе: Современный подход

Главная цель 2026 года для любого разработчика на Битриксе — перестать быть «правщиком файлов» и стать архитектором.

Современный Битрикс — это не только CIBlockElement::GetList. Это:

• D7 ORM для типизированной работы с данными.
• Service Locator для управления зависимостями.
• Routing для чистых URL и API.
• Symfony Console (команда bitrix.php) для CLI-инструментов.

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

Заключение

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

Если вы чувствуете, что «старое ядро» тянет вас на дно, а вы хотите строить системы, за которые не стыдно — пришло время менять подход.