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

Оцінка термінів

Рефакторинг — інвестиція. Його ефект вимірюється не візуально, а у швидкості подальшої розробки та кількості регресій при оновленнях. Щоб отримати консультацію та точну оцінку вашого проєкту, зв'яжіться з нами. Замовте аудит прямо зараз.