Проработав 2 года с CMS Битрикс, у меня сформировалось свое отношение к этому движку. Есть как плюсы, так и минусы, но все же негатива накопилось гораздо больше.

В этой статье я поделюсь своим мнением с читателями и постараюсь описать и хорошие, и плохие стороны этой CMS.

Во-первых, хочется сказать пару слов о тормозах этой системы. В этом ее любят обвинять очень многие.

Для простых сайтов движок вполне подходит и тормозов в этом случае наблюдаться не будет, если, конечно, проектировщик не допустил откровенных ляпов при создании структуры инфоблоков (о том что это за зверь сейчас узнаем).

Тормоза начинаются, когда от сайта требуется что-то большее, нежели обычный текстовый контент. В этом случае проектировщик сталкивается с неуклюжестью движка.
В битриксе все основывается на понятии инфоблока. Давайте рассмотрим что же на самом деле из себя представляет инфоблок.

Инфоблок — это такая сущность, которая объединяет элементы с определенным набором свойств. Часть свойств, такие как название элемента, раздел, даты активности и т.п., присутствует у элементов всех инфоблоков. К этим свойствам проектировщик может добавить еще и свои свойства, но они уже будут рассматриваться в контексте каждого конкретного инфоблока.

Существует также понятие типа инфоблока, который объединяет в себе инфоблоки.
Поясню на примере. Допустим, мы создаем сайт, на котором будут размещены вакансии.. В этом случае нам будут необходимы 3 инфоблока: «Вакансии», «Отрасли», «Компании».

После создания инфоблока «Вакансии» мы можем создать в нем элементы со стандартным набором свойств:

• Название
• Активность (да/нет)
• Период активности (активен в указанный период времени)
• Краткое описание
• Подробное описание
• Изображение-превью
• Увеличенное изображение
• Раздел

Этих свойств будет достаточно для обычного текстового контента (статьи, новости и т.д.), но нам для вакансий этого не хватит. Мы создадим еще свойства:

• Компания (свойство, ссылающееся на инфоблок «Компании»)
• Отрасль (свойство, ссылающееся на инфоблок «Отрасли»)
• Опыт работы (свойство типа список с значениями «до 2-х лет», «от 2-х до 4-х лет», «более 4 лет» и т.д.)

В инфоблоке «Отрасли» и «Компании» ограничимся стандартным набором свойств, которые предоставляет нам битрикс.

Вот, что у нас получилось:

Вроде бы с точки зрения теории баз данных у нас все верно. Все сущности разделены, избыточности нет и т.д. Но давайте взглянем на структуру базы.

Рассмотрим как работает выборка из инфоблоков на простом примере. В битриксе существует часть таблиц в базе данных, которые хранят данные, связанные с инфоблоками — сами инфоблоки (b_iblock), их элементы(b_iblock_element), свойства(b_iblock_property), значения свойств (b_iblock_element_property).

Это не все таблицы, связанные с инфоблоками, но для простоты понимания нас будут интересовать именно они.

Как видим, элементы всех инфоблоков хранятся в одной таблице, все свойства этих элементов так же хранятся в одной таблице.

Как же так! Зачем СУБД копаться в вакансиях, отраслях, если нам нужно будет выбрать всего лишь список всех компаний, вакансии которых храняться в базе ?!

А что будет, если нашему сайту необходим более сложный функционал? Вот тогда то и начнутся тормоза.

Теперь воспользуемся АПИ битрикса и выберем список вакансий конкретной компании, но те вакансии, которые не относятся к определенной отрасли.

В примере происходит выборка из инфоблока «Вакансии», ID которого 23, а также происходит фильтрация по компании, ID которой 373, и по отрасли, ID которой 317. В последнем параметре метода GetList передается список выбираемых полей — ID, компания, опыт работы, начало периода активности вакансии.

SELECT BP.*
FROM
b_iblock_property BP, b_iblock B
WHERE
BP.IBLOCK_ID=B.ID AND B.ID IN (23) AND UPPER(BP.CODE)=UPPER('COMPANY')
 
SELECT BP.*
FROM
b_iblock_property BP, b_iblock B
WHERE
BP.IBLOCK_ID=B.ID AND B.ID IN (23) AND UPPER(BP.CODE)=UPPER('EXPERIENCE')
 
SELECT BP.*
FROM
b_iblock_property BP, b_iblock B
WHERE
BP.IBLOCK_ID=B.ID AND B.ID IN (23) AND UPPER(BP.CODE)=UPPER('BRANCH')
 
SELECT BE.ID AS ID, FPV0.VALUE AS PROPERTY_COMPANY_VALUE, FPV0.ID
AS PROPERTY_COMPANY_VALUE_ID, FPEN0.VALUE AS PROPERTY_EXPERIENCE_VALUE,
FPEN0.ID AS PROPERTY_EXPERIENCE_ENUM_ID, FPV1.ID AS PROPERTY_EXPERIENCE_VALUE_ID
IF(EXTRACT(HOUR_SECOND
FROM
BE.ACTIVE_FROM)>0, DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y %H:%i:%s'),
DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y')) AS DATE_ACTIVE_FROM,IF(EXTRACT(HOUR_SECOND
FROM
BE.ACTIVE_FROM)>0, DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y %H:%i:%s'),
DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y')) AS ACTIVE_FROM
FROM
b_iblock B
INNER JOIN b_lang L ON B.LID=L.LID
INNER JOIN b_iblock_element BE ON BE.IBLOCK_ID = B.ID
INNER JOIN b_iblock_property FP0 ON FP0.IBLOCK_ID = B.ID AND
FP0.CODE='COMPANY'
LEFT JOIN b_iblock_property FP1 ON FP1.IBLOCK_ID = B.ID AND
FP1.CODE='EXPERIENCE'
LEFT JOIN b_iblock_property FP2 ON FP2.IBLOCK_ID = B.ID AND
FP2.CODE='BRANCH'
INNER JOIN b_iblock_element_property FPV0 ON
FPV0.IBLOCK_PROPERTY_ID = FP0.ID AND FPV0.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV1 ON FPV1.IBLOCK_PROPERTY_ID
= FP1.ID AND FPV1.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV2 ON FPV2.IBLOCK_PROPERTY_ID
= FP2.ID AND FPV2.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_property_enum FPEN0 ON FPEN0.PROPERTY_ID = FP0.ID
AND FPV1.VALUE_ENUM = FPEN0.ID
WHERE
1=1 AND ( ((((BE.IBLOCK_ID = '23')))) AND ((((BE.ACTIVE='Y'))))
AND ((((FPV0.VALUE_NUM = '373')))) AND ((( FPV2.VALUE_NUM
IS NULL OR NOT (FPV2.VALUE_NUM = '317')))) ) AND (((BE.WF_STATUS_ID=1
AND BE.WF_PARENT_ELEMENT_ID IS NULL)))
ORDER BY
BE.ACTIVE_FROM ASC

Ужас! А что же тогда творится с СУБД на реальных сайтах.

Мы при написании метода GetList использовали 3 свойства (ключи значений массивов, начинающиеся с «PROPERTY_») и в SQL-запросах, которые сгенерил битрикс, видим 3 запроса для каждого из 3-х свойств. А что будет, если создать десятки свойств? А будет ровно столько запросов сколько участвует в методе GetList.

Ну и в конце мы видим громадный запрос, напичканный join'ами. Если приглядеться к этому запросу, то можно догадаться, что количество join'ов зависит от количества свойств, участвующих в методе GetList.

Понятно, что все это плата за универсальность. Все те, кто используют битрикс любят повторять, что это далеко не идеальная система, но это лучшая CMS из всех существующих. А чем она лучше? Да только, пожалуй, тем, что у нее присутствует больше всевозможных модулей по сравнению с другими CMS. Еще есть удобная админка, в которой быстро разберутся модераторы. Так же битрикс постоянно обновляется и пополняется новыми модулями, в этом тоже его плюс.

Как я уже сказал, мое мнение, что битрикс сгодится только для простых сайтов. Если требуется какой-то более менее сложный функционал, то приходится ломать голову как обойти эти издержки универсальности.

Возникает вопрос. Зачем простому сайту, на котором в основном статьи и новости, дополнительные модули в виде магазина, форума, блогов, тормозной статистики (которую к тому же предлагают многие бесплатные сервисы). А ведь такой сайт программист может без проблем создать, например, на бесплатном фреймворке symfony, в котором админка генерится одной командой. Так зачем платить больше?

Ну а сайт со сложным функционалом, как я уже сказал, по моему мнению начинать делать на битриксе лучше не стоит. Эта затея перерастет в поиски путей обхода битриксовых фич.
И все-таки смысл создавать сайты на битриксе, как мне видится, есть. Но прежде, чем описать свою точку зрения на этот счет, нужно сказать несколько слов о многочисленной армии кодеров-битриксоидов.

Это такие люди, в основном студенты, которые еще не слышали ни о теории баз данных, ни о паттернах проектирования, не работали с существующими фреймворками. Для них битрикс — это все, что стоит за сайтом. Они даже о новых технологиях узнают только тогда, когда она будет включена в очередную версию CMS.

Как-то раз ко мне подошел один из сотрудников за помощью. Он парсил файл CSV, но этот процесс у него отрабатывал не верно. Стали смотреть скрипт и тут программист высказывает свое предположение: «Может быть битрикс где-то закрался?». Может быть всемогущий битрикс каким-то магическим образом и мог бы закрасться в его скрипт, но дело в том, что он его запускал без подключения движка. На самом деле потом нашли обычную ошибку в логике самого скрипта.

Еще был случай. Отмечали чей-то день рождения и двое программистов начали обсуждать все достоинства битрикса. Один из них кинул фразу: «Ну битрикс — это очень мощная система, он внутри себя и язык Си использует, и ассемблер». Второй округлил глаза и не поверил. А тот ему: «Ну ты залезь в код битрикса, посмотри». Тут вообще без комментариев.

Так вот, мое мнение, что создавать сайты на битриксе имеет смысл, но только для менеджеров. Они не знают всех тонкостей работы движка, его подводных камней.
Им выгодно иметь в своем штате битриксоидов, которым не нужно платить нормальные деньги, ведь это еще новичек, который дальше битрикса ничего не видел. Да и работать он будет с системой, в которой уже большинство вещей сделано за него.

Таким образом, на свет появляются web-студии, которые штампуют на битриксе сайт за сайтом. Их основной задачей в итоге становиться увеличение штата сотрудников, способных делать сайты на битриксе. Дешевая рабочая сила. Чем больше штат, тем больше сайтов они смогут клепать.

И напоследок хотелось бы дать совет начинающим программистам. Не устраивайтесь на работу в web-студии, которые в своих описаниях вакансий упоминают слово «Битрикс». Если вы начнете свой карьерный путь с этого движка, то потом соскочить с него будет не просто. Пройдет года 2 и ваши друзья уже неплохо продвинуться в программировании, кто-то перерастет в проектировщика, а вы будете жить одними инфоблоками и не понимать что происходит внутри.
Я сейчас не говорю о всех, но именно таких программистов я встречал часто. Конечно, все люди разные, кто-то может на работе использовать битрикс, но дома в целях самообразования тренироваться в других областях программирования. Но все же лучше набираться знаний на работе, где человек проводит большую часть своего времени.

На этом все. Спасибо за внимание. В комментариях жду ваших мыслей по поводу использования битрикса.