Магазин запустился, продаёт, всех устраивает. А через год каталог вырос, трафик поднялся — и сайт начал тормозить, обновления стали страшными, а любая доработка превращается в лотерею «что сломается на этот раз». Знакомо? Чаще всего дело не в платформе, а в архитектурных решениях, которые поначалу работали, но были антипаттернами — заложенными на старте минами замедленного действия.
В этой статье разберём типовые антипаттерны в архитектуре интернет-магазина на 1С-Битрикс: правки ядра, бизнес-логику в шаблонах, запросы в цикле, игнорирование кэша и версионирования. Для каждого — почему это плохо и как правильно. Цель не пристыдить, а дать карту грабель, на которые не стоит наступать. Разбор и исправление таких проблем — это наш аудит и оптимизация решения на 1С.
Коротко
- Антипаттерн опасен тем, что поначалу работает, а расплата приходит при росте трафика, каталога и команды.
- Правки ядра и логика в шаблонах убивают обновляемость и переиспользование — выносите доработки в модули и события.
- Запросы в цикле (N+1) и отсутствие кэша роняют скорость на большом каталоге.
- Разгребать накопленное нужно итеративно, по приоритету влияния, под прикрытием бэкапов и тестов.
Что такое антипаттерн и чем он опасен
Антипаттерн — это типовое решение, которое выглядит рабочим и даже удобным в моменте, но на дистанции создаёт больше проблем, чем решает. Его коварство именно в отложенности расплаты: магазин запускается, работает, продаёт, и кажется, что всё сделано правильно.
Проблемы всплывают позже и по нарастающей. Вырос каталог — вылезли тяжёлые запросы. Понадобилось обновиться — мешают правки ядра. Пришёл второй разработчик — начались конфликты из-за отсутствия версионирования. Каждый антипаттерн — это технический долг, проценты по которому платятся скоростью, стабильностью и стоимостью поддержки.
Правки ядра платформы
Классика жанра — поправить файл прямо в папке bitrix, чтобы «быстро сделать как надо». Работает ровно до первого обновления платформы, которое затрёт правку и, в худшем случае, сломает магазин.
Ядро 1С-Битрикс обновляется целиком, и любые изменения в нём не переживают апдейт. Правильные способы дорабатывать платформу существуют и хорошо документированы:
- Обработчики событий. Влезаем в логику через события, не трогая исходный код ядра.
- Свои модули. Собственная функциональность живёт в отдельном модуле, а не в чужих файлах.
- Кастомизация шаблонов. Шаблон компонента копируется в свой и правится там, а не в оригинале.
- Слой local. Свой код и правки шаблонов держат отдельно от обновляемого ядра.
Как аккуратно упаковать доработки в переживающий обновления код, мы разбираем в статье про разработку модуля под 1С-Битрикс.
Бизнес-логика в шаблонах
Второй распространённый антипаттерн — писать бизнес-логику прямо в template.php компонента. Посчитать цену, сходить в базу, принять решение о скидке — всё это оказывается вперемешку с версткой.
Проблема в том, что шаблон отвечает за вывод, а не за вычисления. Логика в шаблоне не переиспользуется, не тестируется и дублируется по разным шаблонам, где со временем расходится. Изменение бизнес-правила требует правок в куче мест, и что-то обязательно забывают.
Современный инструмент для такого слоя — D7 и ORM, о котором мы пишем в статье про D7 ORM в 1С-Битрикс: данные и логика работы с ними живут в классах, а не в шаблонах.
Запросы в цикле и проблема N+1
Убийца производительности номер один — запросы к базе в цикле. Выбрали список товаров, а потом в цикле по каждому лезете в базу за ценой, остатком, свойством. На десятке товаров незаметно, на тысячах — сайт встаёт.
Это классическая проблема N+1: один запрос на список плюс по запросу на каждый элемент. Число запросов растёт пропорционально числу элементов, и страница каталога генерирует их сотнями.
- Заметьте симптом. Профилирование показывает, что число запросов растёт вместе с числом товаров на странице.
- Выбирайте пакетно. Связанные данные (цены, остатки, свойства) берите одним запросом на весь список, а не по одному.
- Используйте возможности ORM. Ссылки и предзагрузка связанных сущностей вместо ручных запросов в цикле.
- Проверьте под объёмом. Тестируйте не на десяти, а на тысячах товаров — там антипаттерн виден.
Игнорирование кэша и композита
Магазин, который на каждый запрос заново собирает каталог из базы, обречён тормозить под нагрузкой. Отсутствие кэша — антипаттерн, особенно на витрине, где одни и те же страницы отдаются тысячам посетителей.
В 1С-Битрикс есть несколько слоёв ускорения, и их игнорирование — упущенная производительность:
- Кэш компонентов. Результат работы компонента кэшируется и не пересчитывается на каждый запрос.
- Управляемый кэш. Автоматический сброс при изменении связанных данных.
- Композитный сайт. Статическая часть страницы отдаётся мгновенно, динамика догружается.
- Внешний кэш. Ускорители и кэширование на уровне инфраструктуры.
Про то, как композит ускоряет витрину, мы подробно писали ранее, а инфраструктурную сторону скорости разбираем в статье про хостинг и инфраструктуру BitrixVM.
Кэширование персональных данных
Обратная крайность не менее опасна: закэшировать то, что кэшировать нельзя. Если в общий кэш страницы попадает цена конкретного клиента, его корзина или имя, эти данные покажутся другому посетителю. Это и утечка, и просто неверная выдача.
| Данные | Как отдавать |
|---|---|
| Каталог, категории, карточки | Агрессивный кэш, статика |
| Цена по группе клиента | Динамически, вне общего кэша |
| Корзина и профиль | Только персонально, никогда в общий кэш |
| Остатки по складу клиента | Динамически или коротким персональным кэшем |
Правило простое: статику кэшируем агрессивно, персональное отдаём динамически. Композитный сайт как раз строится на этом разделении — общий каркас из кэша, персональные блоки догружаются отдельно.
Правки на боевом без версионирования
Редактировать файлы прямо на боевом сервере, без Git и без истории изменений, — антипаттерн, который рано или поздно приводит к катастрофе. Потерянные правки, невозможность откатиться, конфликты между разработчиками, «а кто это менял и зачем».
Даже небольшой магазин выигрывает от нормального процесса:
- Контроль версий. Git хранит историю: что, когда и кем менялось.
- Ветки и ревью. Изменения проверяются до попадания на боевой.
- Предсказуемый деплой. Релиз выкатывается автоматически и одинаково, а не «залил файлы по FTP».
- Откат. Неудачную правку можно вернуть за минуты, а не восстанавливать по памяти.
Как выстроить такой процесс на 1С-Битрикс, мы разбираем в статье про CI/CD и деплой в 1С-Битрикс.
Свойства-свалки и плоская структура
Архитектурные антипаттерны есть и на уровне данных. Частый — валить разнородную информацию в одно текстовое свойство или в описание, вместо структурированных свойств инфоблока.
Последствия: по такому «свойству-свалке» не работает умный фильтр, невозможно сравнение, ломается поиск. Плоская структура без нормальной иерархии разделов и типов свойств делает каталог неуправляемым при росте. Правильно — продуманная структура инфоблоков: отдельные свойства под каждую характеристику, справочники для перечислимых значений, разумная иерархия разделов. Тогда каталог масштабируется и участвует в фильтрации, а не только показывает текст.
Синхронные тяжёлые операции в запросе
Ещё один антипаттерн — выполнять тяжёлую работу прямо в пользовательском запросе. Отправка письма, генерация большого документа, вызов внешнего API, массовый пересчёт — всё это в момент клика заставляет покупателя ждать и роняет страницу при сбое внешнего сервиса.
- Выносите в фон. Тяжёлые операции — в агенты, очереди или отложенные задачи, а не в запрос.
- Отвечайте быстро. Пользователь получает подтверждение сразу, работа идёт в фоне.
- Изолируйте внешние вызовы. Падение чужого API не должно ронять оформление заказа.
- Ставьте таймауты и повторы. Внешние интеграции ненадёжны, закладывайте это в архитектуру.
Безопасную работу с внешними вызовами и вебхуками мы разбираем в статье про REST, вебхуки и безопасность в 1С-Битрикс.
Как выявлять антипаттерны
Симптомы чувствуются в эксплуатации, а причины вскрывает аудит. На что смотреть:
- Скорость под нагрузкой. Тормоза на каталоге и в пик — сигнал тяжёлых запросов и отсутствия кэша.
- Страх обновлений. Если апдейт платформы откладывают из-за риска всё сломать — вероятны правки ядра.
- Дорогие мелкие доработки. Простая правка требует изменений в десяти местах — логика размазана по шаблонам.
- Поломки после релизов. Регулярные сюрпризы на боевом — нет версионирования и предсказуемого деплоя.
Точную картину даёт технический аудит кода и инфраструктуры: он находит конкретные антипаттерны и оценивает их влияние, превращая расплывчатое «сайт тормозит» в список приоритетных проблем.
Как разгребать накопленное
Если антипаттерны уже накопились, соблазн переписать всё с нуля велик — и обычно ошибочен. Рефакторинг ведут итеративно.
- Приоритет по влиянию. Сначала то, что бьёт по деньгам и стабильности: тяжёлые запросы, правки ядра, отсутствие бэкапов.
- Прикрытие бэкапами. Прежде чем трогать, убедитесь, что есть рабочие резервные копии и откат.
- Маленькими шагами. Выносите логику из шаблонов, чините запросы, настраивайте кэш по частям.
- Проверка после каждого шага. Убедились, что магазин работает, — двигаетесь дальше.
- Не всё сразу. Работающий магазин важнее идеальной чистоты; чините то, что реально мешает.
Чек-лист здоровой архитектуры
- Ядро не тронуто. Доработки живут в событиях, модулях и своих шаблонах, обновления безопасны.
- Шаблоны тонкие. Бизнес-логика вынесена в отдельный слой, шаблон только отображает.
- Нет запросов в цикле. Связанные данные выбираются пакетно, N+1 отсутствует.
- Кэш настроен осознанно. Статика кэшируется, персональное отдаётся динамически.
- Композит включён. Витрина использует композитный сайт для мгновенной отдачи.
- Версионирование есть. Код в Git, деплой предсказуем, откат возможен.
- Структура данных продумана. Характеристики в свойствах инфоблоков, а не в свалке.
- Тяжёлое — в фоне. Долгие операции и внешние вызовы вынесены из пользовательского запроса.
Вывод
Антипаттерны опасны своей отложенностью: они не мешают на старте и потому легко проникают в архитектуру магазина, чтобы выстрелить позже — при росте каталога, трафика и команды. Правки ядра ломают обновления, логика в шаблонах делает доработки дорогими, запросы в цикле и отсутствие кэша роняют скорость, а работа на боевом без версионирования грозит потерей данных.
Хорошая новость в том, что все эти грабли известны и обходятся стандартными средствами платформы: события и модули вместо правок ядра, тонкие шаблоны, пакетные выборки, осознанный кэш, композит и нормальный процесс разработки. А если антипаттерны уже накопились — их разгребают итеративно, по приоритету влияния, а не героическим переписыванием всего сразу. Здоровая архитектура — это не роскошь, а то, что делает магазин быстрым, обновляемым и дешёвым в поддержке на годы вперёд.
