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

Як проводиться аудит сайту на 1С-Бітрікс?

Навіщо потрібен аудит сайту на Бітрікс?

Зміна підрядника — ви берете проект від іншої команди і не знаєте, які «міни» залишені в коді. Обробники подій у 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 проблем в коді, половина з них — з потенційною втратою даних.

Формат звіту

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

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

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

Що входить у результати?

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

Види аудиту та терміни

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

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