Диагностика техдолга и план рефакторинга: аудит кода 1С-Битрикс

Проблема: каждое изменение — лотерея

Проект работает, но правишь форму обратной связи — ломается корзина. Новый разработчик тратит неделю на разбор структуры, на добавление простой страницы — два дня. Каталог грузится 5 секунд из-за N+1 запросов — клиенты уходят. Каждая секунда загрузки обходится в 100 000 рублей потерянной выручки. Скорость разработки падает, технический долг растёт. Мы знаем, как это исправить. Наш аудит кода — объективный способ измерить техдолг, задокументировать проблемы и спланировать рефакторинг. За 10 лет мы провели аудит более 50 проектов и знаем типичные узкие места Битрикс-разработки.

Какие проблемы типичны для Битрикс-проектов?

На проекте 3–5 разработчиков пишут каждый в своём стиле. init.php разросся до 2000 строк обработчиков, половина не используется. SQL-запросы разбросаны по шаблонам. Инфоблоки создавались без структуры — в одном товары, статьи и баннеры. Каждый фикс занимает полдня, правка рискует сломать соседнюю функциональность. Аудит системно выявляет узкие места и даёт план действий с конкретными сроками. Мы не просто отчитываемся — показываем, как исправить каждую проблему и что даст рефакторинг в цифрах.

Когда нужен аудит кода?

Признаки, указывающие на необходимость аудита:

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

Отличие аудита кода Битрикс от code review

Битрикс навязывает свои паттерны — компоненты, шаблоны, инфоблоки, агенты. Критерии качества привязаны к ним. Обычный PHP-аудит не учитывает специфику API: CIBlockElement, ORM, тегированное кэширование, события. Мы проверяем не только синтаксис, но и соответствие best practices платформы.

Что проверяется: три главные точки

Архитектура инфоблоков. Типичные просчёты: один инфоблок для разнородных сущностей (товары и статьи вместе); свойства типа «Строка» вместо «Справочник» — невозможность фильтрации; отсутствие составных индексов на b_iblock_element_property; хранение данных в PREVIEW_TEXT вместо отдельных полей.

Компоненты и шаблоны. Бизнес-логика в template.php вместо result_modifier.php — антипаттерн. Прямые SQL через $DB->Query() вместо ORM. Кастомизация через модификацию ядра вместо наследования в class.php — проблемы при обновлениях.

init.php. Главный индикатор здоровья. На проблемных проектах — тысячи строк: обработчики, функции, классы, SQL. На хороших — только автолоадер и регистрация обработчиков. Аудит сразу выявляет такие «чёрные дыры».

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

Мы используем монитор производительности (perfmon) и включаем $DB->ShowSQLStat = true. Считаем SQL-запросы на страницу. Норма: 30–80. Проблема: 300+ из-за CIBlockElement::GetList() в цикле (N+1). Также профилируем PHP через Xdebug + Cachegrind.

Инструменты статического анализа: phpstan/psalm — находят обращения к несуществующим методам. PHP_CodeSniffer — проверяет стандарты кодирования.

По статистике, после аудита и устранения проблем производительность вырастает на 40–60%. Аудит окупается за 2 месяца за счёт сокращения времени разработки.

Как проходит аудит: пошагово

1. Сбор кода и базы — копируем репозиторий и дамп.
2. Профилирование — запускаем монитор производительности на типовых страницах.
3. Статический анализ — прогоняем phpstan/psalm, ищем ошибки и нарушения.
4. Ручной аудит — проверяем инфоблоки, компоненты, init.php, SQL.
5. Формирование отчёта — таблица проблем, приоритеты, рекомендации.

Наш кейс: N+1 в каталоге интернет-магазина

Мы вели проект интернет-магазина, где страница каталога генерировалась 5 секунд. Анализ показал: в цикле по 50 товарам для каждого выполнялось 6 дополнительных запросов для свойств — итого 301 запрос. После рефакторинга с CIBlockElement::GetList() и правильным $arSelect количество запросов сократилось до 3, время — до 0.3 секунды. Аудит эффективнее ручного тестирования в 3–5 раз для выявления таких узких мест.

Что входит в отчёт

После аудита вы получаете:

• Таблицу проблем с файлом, строкой, критичностью и рекомендацией.
• Приоритизированный план устранения с оценкой трудозатрат.
• Рекомендации по улучшению архитектуры и производительности.
• Примеры кода для исправления типовых ошибок.

Как заказать аудит?

Свяжитесь с нами для предварительной оценки вашего проекта. Мы предоставим коммерческое предложение с указанием сроков и стоимости. Закажите аудит и получите детальный план рефакторинга с приоритетами и сроками.

Рекомендуем ознакомиться с документацией API инфоблоков для понимания best practices.

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

Представьте: вы открываете проект от предыдущей команды — в 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 рабочий день. Закажите комплексный аудит, чтобы получить полную картину перед серьёзными вложениями.