Я более 10 лет профессионально занимаюсь веб-разработкой. За этот срок мне удалось поковыряться в кишках десятков сайтов — от студенческих поделок до монструозных движков наподобие Oracle ATG Web Commerce.
Примерно 5 лет отдано такому чуду архитектурной мысли, как Битрикс. Об этой CMS написано немало пламенных статей и, как правило, уровень негатива в них прямо пропорционален рейтингу статьи и обратно пропорционален опыту работы с данной системой.
И, в очередной раз наткнувшись на крик души по поводу тлетворного влияния Битрикс на неокрепшие программистские умы, я таки решил вставить свои пять копеек. Точнее, пять секретов, о которых было бы полезно знать веб-разработчикам, впервые сталкивающимся с этим феноменом отечественного ПО.
Секрет № 1. Битрикс — это CMS, а не Framework
Надо понимать, что CMS — это некое готовое решение, претендующее на универсальность. Плюсы и минусы этого очевидны. Если вам нужно быстрое и недорогое решение достаточно распространенной проблемы (сайт-визитка, корпоративный сайт, форум или интернет-магазин средней руки) — вы берете CMS и немного допиливаете под свои нужды. Если вам нужен нестандартный проект либо highload — вы берете Framework и рисуете на нем всё, что захотите.
На практике мне приходилось разгребать последствия внедрения Битрикс в пару интернет-магазинов с дневным трафиком в несколько сотен тысяч / миллионов хитов в день и кучей совершенно нестандартного функционала. Причем делалось это руками (?) вчерашних студентов, имеющих о веб-разработке весьма смутное представление. Результатом таких внедрений становились совершенно безумные архитектурные решения, которые, в сочетании с ограничениями и косностью самого Битрикс, делали жизнь этих проектов совсем невыносимыми.
При этом надо понимать, что издержки на создание серийного сайта на основе CMS на порядок ниже, чем в случае с более низкоуровневый фреймворком. Нет необходимости писать админку — можно за пару часов сконфигурировать ее под конкретный проект. Нет необходимости продумывать архитектуру БД и классов, всё уже написано до вас. Из этого, собственно, вытекает…
Секрет № 2. Не копайте ядро Битрикс
Конечно, в жизни программиста бывают ситуации, когда проще разобраться с исходным кодом программы, чем с документацией (особенно, если ее нет). К модулям ядра Битрикс это не относится. Код ядра по-настоящему ужасен. Движок, который во имя обратной совместимости с самой первой версией, вышедшей на рубеже тысячелетия, толком не реформировался, а только "оптимизировался" и обрастал новыми фитчами, по другому и не мог быть написан.
Хорошая новость заключается в том, что Битрикс обладает сравнительно неплохой документацией и имеет вполне сносное API и всё, что нужно программисту — это API изучить. Если термин "инкапсуляция" вам не знаком, то представьте ядро Битрикс как черный ящик, внутри которого творится недоступная человеческому пониманию магия. Зато наружу торчат ГетЛисты, Апдейты, Делиты и прочая CRUD-дребедень, которой вполне достаточно для нехитрой бизнес логики среднестатистического сайта. Конечно, время от времени магия внутри черного ящика начинает лажать и тогда приходится отладчиком бороздить просторы спагетти-кода. Но это, скорее, исключение из правил и делать это придется нечасто.
Также, возможно, в какой-то момент ваш проект сильно выйдет за рамки стандартного функционала, и имеющихся средств API станет резко не хватать. Это серьезный повод задуматься о смене платформы на что-то более гибкое и низкоуровневое (см. пункт 1). Скорее всего, суровые жизненные обстоятельства отметут такую возможность и вы начнете на свой страх и риск пилить модули Битрикс. Не самая лучшая идея. Кроме проблем с дальнейшим обновлением ядра, это ставит под серьезную угрозу ваш сайт. Как бы не был изнутри страшен Битрикс, его код протестирован на миллионах реальных пользователей. Получится ли у вас так же хорошо протестировать ваши изменения? Лучшей альтернативой будет создание своего модуля. Но для этого нужно обладать достаточной компетенцией как в Битрикс, так и в целом в веб-программировании.
Секрет № 3. Стандартные компоненты Битрикс — в топку
Если от кода модулей Битрикс надо держаться подальше, то код основных компонент лучше не использовать вовсе. Дело в том, что компоненты — это примеры того, как на основе базового функционала (т. е. API) можно создавать различного рода информационные блоки на странице сайта (лента новостей, карточка товара, форма обратной связи и т. п.). Чтобы сделать свои компоненты "по-настоящему универсальными", разработчики 1С-Битрикс решили снабдить их миллионом настроек на все случаи жизни. Жизнь же показала, что в таком виде стандартные компоненты неудобны абсолютно всем — от секретарш до тру-программистов. Секретарши, на которых, видимо, делалась основная ставка, по-прежнему были не в состоянии собрать самый простой сайт без помощи программистов. А программисты и верстальщики усиленно плевались от одного вида любого шаблона с тонной if-ов и непонятных переменных.
В общем, разобраться с этим миллионом настроек и заставить их корректно работать в нужном для вас направлении гораздо сложнее, чем написать свой компонент, оставив в нем ровно то, что вам нужно. Конечно, потребуется некоторое время на то, чтобы на примере стандартных компонент научиться писать свои, но когда это произойдет, вы увидите, что кастомные компоненты на порядок короче и производительнее стандартных.
Лучший, на мой взгляд, способ научиться писать свои компоненты — это оставлять без изменения серверную его часть (component.php) и полностью менять шаблон (template.php), попросту встраивая кусочки данных из component.php в вашу верстку. На этом этапе вы научитесь методом проб и ошибок определять нужные вам настройки компонента и имена нужных вам переменных. Заодно, освоитесь с "философией" Битрикс и изрядно по… любите component.php. В общем, потихоньку разберетесь что в component.php к чему и какая ничтожная часть этого вам реально нужна. Через некоторое время вы предпочтете иметь собственный component.php для часто используемых вами компонент. Вряд ли при этом вы будете использовать настраиваемые свойства, скорее всего, вы просто будете немного модифицировать component.php от проекта к проекту.
Секрет № 4. Не так страшен Битрикс, как его разработчики
В данном случае я имею в виду не калининградских разработчиков CMS 1С-Битрикс, а тех кашеваров, которые на этой CMS клепают сайты по пять рублей за пучок. Их толпы и имя им — легион. Можно ли обвинять в жадности заказчиков, предпочитающих работу инжинегров работе качественных специалистов? Вряд ли. Абсолютное большинство заказчиков попросту не обладают достаточной компетенцией для того, чтобы отличить качественно сделанный сайт от некачественного. Ведь судят по одежке — по внешнему виду сайта и наличию требуемого функционала, а не по качеству сборки. А если не видно разницы — зачем платить больше?
Разница становится заметна обычно только на этапе промышленной эксплуатации, когда исполнитель уже получил деньги за работу и думать про нее забыл. Вдруг оказывается, что сайт, показывающий отличные результаты на тестовой базе в 10 товаров и паре одновременных юзеров, сломался при наплыве аж десяти пользователей и базе в 1000 позиций. Кроме того, оказывается, что сам процесс добавления товаров вызывает дикую головную боль и грозит затянуться на годы. Ну а что делать, ведь заказчик даже не обсуждал этот вопрос с исполнителем, а исполнитель сделал тяп-ляп, лишь бы было. Да и смысл ему напрягаться за такие крохи? Ну и, наконец, стали исчезать заказы интернет-магазина!
У заказчика возникает закономерный вопрос: "Кто виноват?" Сам он, естественно, быть виноват не может. Не мог же он заранее об всем этом знать? Он находит исполнителя, но тот тоже прав — он сделал всё, о чем договаривались. А то, что сайт висит — так это ж Битрикс, что вы хотите? Возьмите сервак помощнее, выделенки с 64Gb оперативы на 1000 товаров и 10 пользователей должно хватить. Неудобно рабоатать в админке? Ну это ж Битрикс, я вам говорю! За полтинник так и быть, сделаю вам форму поудобнее. Пропадают заказы? Ну не знаю, когда мы проверяли — всё было в порядке. Может, Битрикс глючит? Ладно, давайте еще полтинник, посмотрю. И клиент платит. И за выделенный сервер, и за формочку, и чтоб заказы не пропадали. А кто виноват? Конечно, Битрикс!
Ну ладно, а что, если бы заказчик сразу пошел в дорогую веб-студию, имеющую внушительное портфолио и высокий рейтинг среди партнеров Битрикс? Получил бы он сразу хороший и удобный сайт? Да, шанс получить качественную работу был бы выше, но не факт. Помните те два интернет-магазина с миллионной аудиторией и нестандартным функционалом из первого пункта? Оба они были сделаны отнюдь не фрилансером, а очень даже дорогой веб-студией, позиционирующей себя как Лидер в разработке интегрированных и высоконагруженных интернет-решений! Эта уважаемая контора не постеснялась взять за те проекты многие миллионы рублей, из которых, наверное, тысяч сто перепало непосредственно студентам-разработчикам.
Как можно догадаться, вышеперечисленные проблемы не имеют непосредственного отношения к Битрикс. С тем же успехом горе-программисты могли бы спихнуть свои проблемы на любой другой движок, с которым им пришлось работать. Другое дело, что Битрикс лучше других подходит на роль козла отпущения, поскольку в коммерческих целях позволяет себе многократно преувеличивать достоинства своего продукта и имеет в определенных кругах довольно скверную репутацию.
Секрет № 5. Почему клиенты выбирают Битрикс
Действительно, многие разработчики искренне не понимают, почему клиенты хотят сайт непременно на Битрикс, а иногда приходят в веб-студию с уже купленной коробкой. Попытки "умных" программистов вразумить "глупых" клиентов и заставить написать сайт на каком-нибудь кошерном движке зачастую не имеют эффекта. Причин этого несколько и они довольно банальны.
Во-первых, Рыжиков & Ko проводят довольно грамотную маркетинговую политику, подружились с 1С и другими нужными людьми, не гнушаются проводить бесконечные презентации своего продукта и благотворительные семинары по его изучению. Они ввели сертификацию разработчиков и веб-студий, дают разработчикам щедрые чаевые за продажу лицензионных копий и вообще очень много работают над тем, чтобы упаковка их коробки была самой яркой, а логотип в виде буквы "b" смотрел из каждого угла. Стоит ли после этого удивляться, что среднестатистический клиент хочет именно Битрикс, а не ваш кошерный движок? Нет, удивляться стоит тому, что создатели кошерного движка не приложили должных усилий для продвижения своего детища на рынок веб-разработки.
Во-вторых, даже искушенный в веб-разработке заказчик хорошо понимает, что программистов под Битрикс — пруд пруди, а из разработчиков кошерного движка он знает только вас. А значит, если в какой-то момент ваши пути разойдутся, ему будет очень тяжело/дорого найти других разработчиков для поддержки сайта. Такой крючок заказчиков реально пугает. Другое дело, если сайт написан на Битрикс. Даже если он написан плохо, огромное количество студий сразу скажут, что имеют исключительную компетенцию в разработке на этой CMS и им не составит труда быстро во всем разобраться и, если надо, переписать. Естественно, на Битрикс.
В-третьих, Битрикс реально развивается и прирастает не только новыми фитчами, но и улучшениями в плане производительности и безопасности. Пусть кишки его по-прежнему ужасают, а количество файлов в дистрибутиве экспоненциально растет, клиента это волнует в последнюю очередь. Кроме того, у клиентов есть уверенность в том, что это развитие не прекратится, а коробка, купленная в две тысячи лохматом году, может быть обновлена до последнего байта. А как обстоят дела с вашим кошерным движком?
Заключение
В качестве заключения хочу еще раз пожелать разработчикам выбирать верные инструменты для своих задач. Не пытайтесь писать на Битрикс игру или онлайн-аукцион — это не его задачи. Битрикс не позволяет даже создавать свои категории объектов (сущности), можно использовать только те, которые зашиты в модули его ядра.
Не стоит брать Битрикс для разового проекта, тем более сложного. В силу определенных исторических причин эта CMS обладает очень тяжеловесной и запутанной архитектурой. Попытки взять Битрикс кавалерийским наскоком могут закончиться болью и страданиями даже у бывалых программистов. К Битрикс надо привыкать. Поэтому выбирать его в качестве CMS имеет смысл, если, например, вы планируете поставить на поток создание достаточно однотипных сайтов. При желании можно научиться делать их быстро и в довольно сносном качестве. Другой вопрос — насколько быстро вам это надоест.