Всем привет. Это мой первый пост на хабре. Поэтому представлюсь для проформы. Веб-разработчик. Опыт 3,5 года. В настоящий момент — состоявшийся битриксоид. Занимаюсь всем — поддержкой крупных проектов, собственной разработкой, консультацией в вопросах маркетинга, обзором возможностей новых версий, нюансами интеграции сайта с 1С на стороне оной, написанием модулей для marketplace, внедрением бизнес-процессов в «Корпоративный портал». И многим другим. В рамках отдельно взятой CMS. К счастью ли, к сожалению ли (в статье об этом и пойдет речь) — без работы остаться невозможно. Рынок наполнен продуктами от 1С-Битрикс более, чем наполовину.

В статье речь пойдет о плюсах и минусах этой монополии. А в том, что тенденции для этой монополии есть — лично у меня никаких сомнений.

Я намеренно не начал свой пост с фразы «это не очередной пост о преимуществах и недостатках». Пусть это будет очередным постом. В вопросах велосипедостроения я не силен. Так что и пост будет использовать готовые идеи и готовые решения. Все как в Битриксе.

Так почему же Битрикс не любят? И кто его не любит?

Как мне видится — есть две основные группы.

1. Менеджеры и заказчики, от самой разработки далекие, но уже набившие большое количество шишек в разработке сайтов. И имеющие свое мнение.
2. Разработчики — сторонники «кошерной» и «идеальной» разработки. На фреймворках или собственноручно написанных.

Первая группа. Менеджеры и заказчики.

Я достаточно часто работаю с людьми, которые заказывают Битрикс из-за того, что он имеет огромный ряд преимуществ в управлении сайтом. Эти люди понимают за что платят деньги и почему покупают именно Битрикс, а не используют бесплатную CMS или ту, что подешевле. Таким мне не нужно приводить аргументы, составлять перечень преимуществ, недостатков. Они сами все знают.

Увы, в эту группу попадает и много людей, которые читать не любят. То есть — нужно сделать сайт. Ок, щас сделаем. А на чем мы его будем делать? Смотрим рынок. Битрикс покупается — ок, берем его, дальше разберемся. Ну, или наймем специалиста, который разберется за наши деньги.

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

Я не говорю о том, что человек компетентный Битрикс не закажет. Но я говорю о том, что целевая аудитория продаж — это те, кто в кухне разработки сайтов смыслит примерно также, как и выпускники курсов «PHP за 24 часа». Это печальный факт, но как по мне — это элементарная плата за популярность. К самой системе не имеющая прямого отношения.

Огромное количество фейлов на моей практике основаны на следующих стереотипах:

1. Интеграция с 1С бесплатная и стандартная

. На эту тему можно почитать хотя бы вот эту статью habrahabr.ru/post/137888, в которой очень хорошо описаны риски. В статье описаны проблемы уже опытной студии. А о студиях, в которых разработка только делает первые шаги — и говорить не приходится.

В итоге что имеем на практике — дизайн магазина на 20-30 страниц. С навороченными фильтрами, красивыми выпадающими из меню разделами, все переключается, жмется и выпрыгивает. Клиент говорит «хочу», составляется контракт, дело передается в отдел разработки.

И тут звучит эпик-фраза менеджера:
«Тут есть заказик, но у клиента еще есть база в 1С на 100500 товаров, но в Битриксе же это стандартно, да? Просто без интеграции он сайт не примет. А ты говорил, что это стандартно...»

— Ок, давай посмотрим базу. Дизайн вы ведь еще не делали?
— Мы его уже утвердили, сейчас работает верстальщик
— Хорошо, а в каком состоянии база, совпадает ли структура?
— Мы не знаем, программист 1С сейчас в отпуске… Но какая разница, потом если что — доработаем. Нам ведь главное интегрировать.

«Ок, интегрировать так интегрировать, че мне сложно в самом деле, тем более это стандартно» — ёрничаю я про себя, и не ожидая ничего хорошего — начинаю бесконечную переписку с 1С-прогером. Кто хоть раз занимался вопросами интеграции чего-либо с 1С должен меня понять. В 90% случаев о какой-либо структуре говорить не приходится. Свойства товаров занесены в текстовые поля, часто с ошибками, вложенность товаров нулевая, и проч, и проч… А у нас дизайн сайта утвержден, с юзабилити и в ТЗ вписан пункт об 1С. И это еще хорошо, если 1С-ник заинтересован в сдаче сайта также, как и мы. А если это просто человек на ставку, то все эти наши нестандартные задачи, ему будут как зайцу стоп-сигнал… Ответит «Ребята, у вас просто нет опыта интеграции с 1С, о чем мы разговариваем? Какие доработки?», как в случае с программистом 1С из вышеприведенной статьи.

Кто уже собрался предлагать решения и возможные выходы из ситуации, то скажу — расслабьтесь. Фейл уже состоялся. Дальнейшая разработка превращается в бесконечную череду костылей. Ничего хорошего из нее уже не выйдет. Либо красивый дизайн пойдет под медный таз, либо никакой стандартной интеграции не будет и кому-то придется ручками заполнять недостающие свойства, и ручками же переводить структуру в удобоваримый для сайта вид. Или будет интеграция через какие-нибудь CSV файлы. А в этом случае — у разработчика только одна забота — сдать сайт быстрее, чем на нем полезут косяки с базой.

В чем проблема? В некомпетентности. И в отсутствии привычки думать. Нам же надо сайты делать, а не думать. Вот мы и делаем, как знаем: Юзабилити — Дизайн — Верстка — Разработка. Что может быть проще? Увы, есть нюансы и их надо понимать.

Когда фейл происходит — разочарование в Битриксе достаточно сильное. «Мы-то думали, а тут нам подсунули». Плюются все — начиная от заказчика, заканчивая разработчиком (да, бывали случаи, когда и сам думал, что легче уже было бы вручную все эти нестандартные интеграции писать с этими нестандартными сайтами, чем запихивать в Битрикс свои художества).

В этом первый (и ИМХО — главный) минус Битрикса. Попсовость и популярность, идущая в ногу с обывательщиной. Даже в студиях, имеющих полный набор сертификатов, золотые статусы всегда найдется менеджер, который «продал сайт за большие деньги» и посчитал свою работу выполненной. И на радостях пустивший дальнейшую разработку на самотек, мол — мое дело за сроками следить, а там вы уже сами разберетесь, задачи я озвучил.

2. Прочие стандартные возможности

В статье я специально уделил много внимания самому популярному фейлу в работе с Битриксом — его недостаточно прозрачно описанной связи с 1С. Это для разработчика понятно, что не все так просто. Менеджер и заказчик чаще всего посчитают, что связь простая, бесплатная и не занимающая времени. И объяснить им всю сложность, оказывается, далеко не всегда просто. В силу того, что им просто не надо знать лишнего.

Но из этой же серии проблема со стандартными возможностями, которых у системы на самом деле — очень и очень много. Стандартные модули, компоненты, насыщенные функционалом… Ведь все это тоже чаще всего накрывается одним росчерком юзабилити. Нарисовали оформление заказа в один шаг во всплывайке и с доп. полями — клиент утвердил. Первый вопрос — зачем рисовали в один шаг, если в стандартном компоненте битрикса оформление заказа идет в три шага? Разве это так принципиально для сайта? Не понимаю — бизнес клиента пойдет под откос, если мы сэкономим 10 часов разработки и снизим риски за счет использование стандартного функционала?

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

И это следствие первого минуса Битрикса. Некомпетентность и непонимание как работать с системой.

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

Даже в случае создания большого сайта с несколькими десятками типовых страниц — все ведь крутится вокруг одних и тех же компонентов: catalog, news.list, iblock.element.add.form. В крайнем случае нужно фильтры каталога доработать немного. Но опять же — не более 10% отклонения от стандартного функционала. Когда вся разработка сводится к допиливанию исключительно файлов template.php и result_modifier.php. ИМХО, при большом желании этому можно обучить даже верстальщика, который умеет использовать только две php конструкции: foreach и if

3. Создание сайтов на Битриксе — это просто (это сложно)

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

Увы, в моей практике, только малая часть менеджеров удосужила себя прочтением курса «Контент-менеджера» хотя бы. Хотя его, конечно, мало. Зато в моей практике было достаточное количество людей, которые каждый раз перед созданием совершенно типового интернет-магазина спрашивали «а возможно ли ЭТО реализовать на битриксе?». Про себя я думаю «Ну, если бы ЭТО невозможно было реализовать на битриксе, то зачем вы вообще хотите заказать разработку на нем? Исходя из каких соображений?». Соображение, увы, чаще всего одно: «Да мы тут посмотрели какие CMS сейчас популярны и решили заказать сайт на нем».

Ребята, вы сэкономите себе кучу нервов и денег, если просто прочитаете описание возможностей стандартных компонентов, и попробуете поработать с ними в режиме визуального редактирования. Может быть даже составив таким образом небольшой сайтик без верстки. Это и вправду не требует больших усилий, а в дальнейшем при заказе сайтов пригодится более чем. Документация по системе ведь очень неплохая.

4. Сайт очень медленно работает

Сайт на Битриксе может работать медленно по многим причинам. И ни в одном из этих случаев не виновата сама система. Вина может быть в некорректно подобранном хостинге, в разработчике, который написал свои компоненты и не озаботился подключить кеширование, вина может быть в чрезмерно нагруженном макете. Но сама система не виновник того, что главная страница сайта у вас загружается 5 секунд. Это опять же стереотип, который любят повторять менеджеры и люди, далекие от разработки. Что Битрикс — это тяжело и медленно. Поверьте, если все сделать правильно — сайт на Битриксе будет летать. Вопрос только в том, чтобы все сделать правильно и понимать, что такое правильно, а что такое — неправильно.

Вторая группа. Разработчики

Автор статьи (то есть я) — сам разработчик. Начинал не с курсов «php за 24 часа». К примеру, на каком-то уровне знаю ассемблер. Есть пара коммерческих проектов на Delphi, да и веб начинал постигать с самых азов — учебник Котерова, статьи о паттернах программирования на инглише. Писал на Zend Framework, Yii. Есть фреймворк, написанный мною, с нуля. На котором тоже есть проекты, реально работающие. Иногда в свободное время пишу небольшие программки на php для собственных нужд, начиная с создания файла index.php в пустой папке. Просто, чтобы не забывать основ.

Но — у меня никогда не возникало желания сказать, что разработка на Битриксе ХУЖЕ или разработка на Битриксе ЛУЧШЕ, чем разработка на чем-либо другом. Это могут позволить себе люди из первой группы. Но когда такую глупость говорят разработчики…

Как по мне — такие стереотипы у профессионалов основаны на извечном биче любого разработчика — стремлении к идеалу. Любой программист в душе законченный перфекционист и точно знает, что такое «идеальная разработка». И любой лелеет в себе мечту создания фреймворка, на котором можно писать любой сайт быстро и без единой проблемы. А все, что написано не им любимым — то по определению «говнокод», «ничего незадокументировано», «не структурировано», «глобальные переменные по всему коду — о чем можно говорить вообще?» и т.п.

Хотя в целом — я с ними бываю согласен, когда поступает заказ на доработку проекта на Битриксе. Вот так, бывает, откроешь какой-нибудь шаблон вывода карточки товара, а там хлебные крошки выводятся с помощью пяти (!) sql запросов к базе (прямых, без всякого АПИ), то тут конечно тяжело вздыхаешь. Говоришь клиенту или менеджеру — извините, но доработки вашего сайта обойдутся вам дороже. Клиент вздохнет «Ох уж этот Битрикс...»

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

Справедливости ради, замечу, что сам с опаской заглядываю в код стандартных компонентов. Там много интересных вещей приходится увидеть. Но все же — стандартные компоненты писались программистами хорошего уровня (уж, по крайней мере, выше того, который крошки sql запросами выводил). И — как я выше писал — ну идейно, стандартный компонент — это черный ящик. Он просто должен делать свою работу. Не для доработок он. Это вина проектировщика, который составляет макеты под Битрикс. Это он в первую очередь должен понимать, что дорабатывать стандартные компоненты Битрикса — это сложная задача, и чреватая рисками. Хочется кастомности для простейшей задачи — сядь, нарисуй на листике то, что ты хочешь. И потом сравни их с тем, что уже есть, поиграв компонентами в визуальном редакторе.

Если проект слишком уж отклоняется от функционала самого Битрикса — то сядь и подумай, а так ли уж важно для бизнеса использование именно этой системы, не логичнее ли заказать другую? Впрочем, в том и в том случае — речь не о разработке, речь о тех людях, которые продают/заказывают сайты.

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

Привыкнуть к Битриксу можно точно также, как и к любой другой системе. Это мое полное убеждение. И получать удовольствие от собирания сайтов на нем — тоже не так сложно.

В качестве эпилога хочу сказать, что в любом деле важен грамотный подход и изучение предмета. Просто так схватить модную вещь, не изучив для чего она и как ей пользоваться, в надежде, что она принесет сразу золотые горы — не выйдет. Любой проект — это работа. И выбор инструмента — здесь всего-лишь один из этапов работы. И далеко не самый важный. Куда важнее — умение пользоваться этим инструментом. Статью я назвал «CMS от маркетологов. Плюсы и минусы». Надеюсь, в статье примерно удалось изложить о чем я вел речь.