Началось вся эта затея в 2009 году, когда я решил использовать в своих проектах (то есть, компоненты-пустышки для создания на них произвольной логики с помощью API-функций Битрикса). Тогда основным профилем моей деятельности была заказная разработка нестандартных решений, фактически, я три года работал на одном разветвленном проекте, сопровождая его, и поддерживая группу сайтов в одной многосайтовой системе (накопилось около 23 сайтов) автомобильной тематики. Идеологически было решено создавать новые сайты - как дополнительные сайты, это было экономически выгодее, плюс все они были рамках одной компании, и придавали удобство в управлении и сопровождении. Хотя, сейчас я понимаю, что возможно правильнее было бы создавать их как отдельные сайты, но сейчас не об этом, сайты довольно успешно работают и выполняют свои задачи. Я хотел поделиться наблюдениями и умозаключениями из практики, с которой мне пришлось столкнуться, и вследствие чего я полностью пересмотрел своё представление о проектировании сайтов на Битрикс с точки зрения компонентов.
По воле случая попал в интересный проект, при котором нужно было очень быстро разворачивать много сайтов на Битриксе, по 40 сайтов в месяц (да, это так), имея в штате всего три php-разработчика (двое из них - совсем начального уровня, абсолютно без знания Битрикс, и с опытом в программировании на php до одного года, ну и третий - ваш скромный слуга). При этом имелся довольно солидный штат менеджеров в 25 человек, который обеспечивал хороший поток новых сайтов на холодном обзвоне. Задача была простая - если за два месяца удастся наладить производство - то тогда всё отлично, и эта штука будет жить, если нет - то тогда инвестированные денги заканчиваются, нечем платить зарплату и аренду, и приходится расходиться. Решил попробовать, хоть и рискованно что может не получиться, но зато весело, и всё только от тебя зависит. Скажу сразу, таким трудоголизмом как в те два месяца - я никогда в жизни так не работал. Бывало, конечно, когда нужно подзаработать брал подработку и работал до 4-х ночи, при этом на 9 утра идя на работу, но в таком режиме работал максимум неделю, после этого все выходные отсыпался. Но не в этом случае, тут у меня такой раш продлился более двух месяцев, но результат стоил того.
Так вот, идея, которую я хочу поделиться - состоит в том, что на стандартных компонентах можно быстро и много делать довольно хороших сайтов.
До недавнего времени, я был убежденным сторонником разработки на своих компонентах, все проекты, которые я делал (на фирме или на фрилансе) были написаны исключительно на одном компоненте, в файле result_modifier.php которого я добавлял требуемую логику, выбирая из базы только нужное, скурпулезно оптимизируя запросы, и получал вылизанное идеальное решение, работавшее максмально быстро, насколько это возможно в Битрикс. На написание подобного кода иногда уходили дни или недели, но времени было достаточно, фирма была большая (свыше 1500 человек), я был одним из сотрудников, который мог получать месяцами зарплату, и никто в другом отделе, или даже непосредственный руководитель - не знал чем я занимаюсь. Это было отлично, я мог писать сложнейший навороченный код, оптимизировать и писать прикольные штуки. Но, потом, когда понял, что способен на большее и хочется полнее реализовывать свои возможности, захотелось идти дальше, и ушел в этот новый проект. Здесь всё обстояло по другому, каждый день был на вес золота, и дополнительные пару часов, которые у меня выдавались вечером для программирования, когда я отключал аську и одевал наушники, были для меня невероятно ценны, так как можно было успеть запрограмить новый важный фукнционал.
Но понятно, что самому всё не сделаешь, нужны были помощники, на которых можно переложить неинтересную или механическую работу. При этом нужно было обеспечить им максимально четкие и простые инструкции, с которыми они бы создавали большое число сайтов. Сделал "простенький" конструктор, который создавал сайт с помощью заготовки, пару вариантов для выбра дизайна, парсер для перегона контента и с других сайтов, мастер настройки , параметров и доступов, и вперед. Вначале для меня было психологически трудно поверить, что за день можно сделать хотя-бы 4 сайта, так как до этого средний срок на создание сайта средней сложности был в лучшем случае пару месяцев. Но тем не менее, это возможно. Имея в штате дизайнеров, которые рисуют типовые дизайны за два-три дня (с четким набором бизнес-требований как можно и как нельзя рисовать), верстальщиков (либо фрилансеров) которые этот шаблон за день-два сверстают, и программистов, который натянет сайт на типовые компоненты за пару часов, можно на потоке спокойно выпускать по несколько сайтов в день.
Так вот, к чему я веду, если бы каждый компонент и каждый функционал писался индивидуально (даже имея примеры кода с прошлых сайтов), то всё равно это было бы долго. Если программист будет делать сайт больше дня, или если будет делать что-то слишком нестандартное, то на него может навалиться гора незавершенных сайтов и бесконечных доделок, поэтому всё должно быть просто и быстро, и надежно чтобы в последствии к этому не возвращаться, и чтобы кто-то другой мог доработать код первого программиста. Так как времени на обучение небыло, было решено всё делать на стандартных компонентах, в большинстве случаев программисты правили только шаблоны (этому научиться довольно просто, имея базовые знания html+php), и поняв, что такое компоненты, и что такое инфоблок. Задача предельно простая, добавляешь на страницу компоненты (меню, соц. закладки, поиск, форму обратной связи, хлебные крошки, новости, простенький каталог товаров), добавляешь включаемые области, слайдер, пару if-проверок в одном шаблоне (для главной и внутренних страниц), и всё, простенький сайт-визитка готов принимать своих первых посетителей. Так же имелся штат контент-менежеров, которые довольно лихо эти сайты наполняли, для них обучение проходило вообще быстро, так как документацию никто из них и не подумал открывать, было достаточно им хорошенько , оставив возможность менять только то, что нельзя поламать), и кинуть их на амбразуры. Я им оставил возможность менять только css-код шаблона (и то, не весь, а вынес его в отедльный файлик, и дал доступ только на него, через админку Битрикса), чтобы они могли переопределять стили, а так же имели доступ на вставку яваскриптов, и редактирование включаемых областей.
Но вернемся к программистам, тут самое интересное. Как-то на одном сайте мне нужно было сделать фотогалерею, всё как положено, на разделах и элементах, элементы строятся и подставляются в верхее выпадающее меню, автоматическое подставление фоновой картинки на основе первой картинки раздела, слайдер, увеличалка, и тд и тп. И сделать это нужно было буквально за пару часов, так как к концу дня в офис приезжал клиент, смотреть уже готовый сайт, и если бы он ему понравился - платил сразу деньги. Если нет - уехал бы и забыл бы про сайт (такой вот капризный клиент), но интересен сам челендж. Готового кода именно под этот случай у меня небыло. Вначале подумал, возьму, напишу код для выборки элементов, запихну его в menu_ext, напишу компонент каталога и тд. Но потом понял, что во первых, на это нет времени, а во вторых, потом этот код после меня будет дорабатывать программист-стажер (когда клиент захочет улучшение и развитие дальше), а времени рассказывать что это такое, и обучать его, опять нет. Решено, возьму компонент bitrix:menu.sections и положу его в menu_ext (вместо самописного кода), прикручу стандартные bitrix:catalog, со своими монстрообразными bitrix:catalog.sections и пусть себе крутится. Вначале для меня это было психологически сложно, как так, куча лишних запросов, неоптимальное кеширование, куча лишних файлов шаблонов, которые не используются (а просто копируются при копировании шаблона bitrix:catalog "за компанию"). Но выхода небыло, сделал. Действительно, быстро, просто, эффективно, хоть и слегка говнокодно (или, точнее сказать, не оптимально по производительности).
Но потом я решил посмотреть на это с другой стороны. А действительно ли это не производительно? Сайт посещать будет от силы 100 человек в день (если 500 - ну вааще супер), но даже при такой нагрузке время генерации страницы мизерно мало (0.01 сек или что-то такое), так как быстрый мощный хостинг. К слову о хостинге, решил не париться, взять shared-хостинг одного из битрикс-хостинг-партнеров, в котором удобная админка, легко добавлюятся сайты, легко нарастить производительность, легко передать сайт клиенту в случае если он решит дальше сам сопровождать сайт, относительно надежный, и что самое интересное - стоит копейки. Называть его не буду, думаю все и так знают какой самый популярный российский хостинг для битрикс-сайтов я имею ввиду, и который в последние годы хоть и испортился, но свою задачу по очень быстрому и очень недорогому хостингу - довольно успешно решает.
Так вот, время, которые я (или другой программист) потратили бы на оптимизацию кода, кеширования и пр, стоит в десятки, а то и в сотри раз больше, чем банально выделить дополнительное место под файловый кеш, которым так нещадно обрастает Битрикс (ну и, конечно, не забыть поставить автоочистку кеша раз в пару месяцев по крону, чтобы совсем не зарос), и банально докупить серверных мощностей. В наш цифровой век стоимость выходит действительно смешной, и как я вижу, дальше она только уменьшается. Даже тот-же Google использует в своих дата-центрах большое количество простеньких серверов. Более мощный сервер или больше дискового пространства - стоят реально на несколько порядков ниже времени работы программиста, это факт. Решающем показателем эффективности является время, чем быстрее сделал, тем больше заработал.
Здесь я не говорю про говнокод, как в примере когда , у нас такого нет, всё делается строго, на компонентах и в рамках четкого следования иделогии Битрикс (все сайты проходят монитор качества, это так же было одним из условий). Но, единственная ложка дегтя - делается это всё неоптимально по запросам и лишнему коду. Ну вот, взять хотя-бы компонент bitrix:catalog, и фотогалерею, сделанную на нем. Зайдя в параметры комопнента видим - типы цен, сравнения товаров, и прочую чепуху, зачем это в фотогалерее? Правильно, не зачем, но клиент не будет заходить в настройки, и программист не будет (ну, может, разок, на этапе программирования), и еще может быть еще разок, когда нужно будет что-то подправить. Конечно, поплюется, , поставит нужную галочку, но оно будет работать, и будет работать так, как нужно, и галочка (например, показывать элементы подразделов) там будет всегда, она знает что она там есть, и он её нажмет, а не будет писать свой код для выборки в api, тратя на это драгоценное время (жизнь).
Дальше больше. Сайты-визитки, конечно, хорошо, но возьмем магазины. Большинству представителей мелкого бизнеса нужен магазин чтобы быстро начать продавать, а они совсем не бум-бум в интернет-технологиях, но знают что Битрикс это круто, и хотят на нем магазин, и готовы платить, только бы им сегодня уже дать магазин, прикрутить простенький контекст, чтобы они ринулись увеличивать свои продажи. В магазине уже сложнее обойтись без стандартных компонентах, и наоборот, здесь они раскрываются во всей своей красе. Я бы не рискнул писать свои компоненты оформления заказа или компонент последних просмотренных товаров, или лучших продаж, или отзывов, или козрины. Конечно, хорошо когда под рукой есть готовые наработки, или свои компоненты корзины или отзывов, но их написание с нуля занимает прилично времени, и что еще важно - их сопровождение и постоянный допил. А так - этим допилом занимается сам Битрикс (хоть и редко, но бывает), но тем не менее это всё работает. Пусть отзывы и одноуровневые (и зачем-то на модуле форума), пусть на каждый просмотр товара делается апдейт-запрос на обновление счетчика просмотров, пусть корзина делает тучу лишних проверок, но всё это сможет подключить программист без опыта работы с минимальными трудозатратами, и даже то-т же фильтр лучших товаров вполне может быть реализован на bitrix:catalog.top и вполне нормально и быстро работать, как для штатного компонента.
Конечно, идеально бы если бы разработчики Битрикс прислушались и добавили поддержку , котором , тогда бы необходимость кастомизации штатных компонентов была бы еще меньше (фактически отпала), а если еще и $arParams (пусть даже не явно выведенных в параметрах компонента, но присущствующих в компонентах, чтобы разработчик мог их пользовать в нужный момент), то вообще бомба. Причем, я так смотрю, что идея работы только на стандартных компонентах далеко не нова, и многие продвинутые разработчики в курсе этой фишки, и , если проект с посещаемостью до тысячи человек в день. А то и больше.
Резюмируе вышесказанное, стандартные компоненты довольны круты, если правильно их готовить.
Плюсы:
- значительно сокращается время на обучение разработчиков
- наличие готовой докуменации
- наличие готового функционала (каталог, новости, отзывы, рейтинги, сравнение, корзина, лучшие товары, карта проезда, соц. кнопки и тд)
- довольно высокая функциональность через настройки без программирования
- идеологически просто дорабатывать проект разными программистами
- заказчику понятнее что это компонент "список новостей", а это компонент "каталог", чем если бы это был один компонент
Минусы:
- неоптимальное количество запросов, возможна более низкая производительность на высоконагруженных проектах
- невзоможность применения на сайтах с нетиповым функционалом
Первый минус - возможное снижение производительности за счет неоптимального числа запросов - будет проявляться только на действительно высоконагруженных проектах, где обычным наращиванием серверной мощности уже не обойтись. И то, этот лимит довольно далеко, так как с точки зрения эффективности бизнеса - дешевле докупить серверной мощности, чем платить за часы разработчика. Но мне пока что сложно представить, чтобы сервер ложили обычные компоненты вроде bitrix:catalog.section или bitrix:catalog.element. Да, они чуть медленнее, но не настолько, чтобы ложить сервер, скорее это только моральный дискомфорт с точки зрения разработчика, что его компоненты вытаскивают лишние данные на каждом хите (например, данные о разделе), когда нам нужен только список элементов, но на деле это практически не заметно, и банальные настройки конфигурации сервера влияют на производительность в разы выше и существеннее, чем лишняя выборка в компоненте.
А сайты с нетиповым функционалом - на то и нетиповые, для них проще написать один раз свой персональный компонент, сделав впоследствии этот компонент типовым, и тиражировать его на остальных сайтах уже как типовой компонент.
Ну, и если сайт совсем уже нетиповой - то конечно да, стандартным компонентам здесь не место, но возможно, что тогда и Битрикс выбрали не совсем правильно, лучше уж запилить это всё на каком-нибудь Zend Framework, и не плеваться на отсутствие недостающего функционала. Битрикс - это коробочный продукт, предназначенный для коробочных сайтов, иногда проще взять коробочного клиента, или переубедить его, что ему нужен коробочный продукт на котором будет такой-то раздел с новостями и такой-то функционал отзывов или рейтинга, вместо того чтобы вступать в дискуссию и идти на поводу, допиливая что-то нестандартно-индивидуальное, на что Битрикс с никак просто не способен. Здесь проще взять другой инструмент, и не рубить бревна лобзиком (или забивать гвозди микроскопом), а просто грамотно убедить, что такое инструмент для продаж (по большему счету заказчик заказывает у вас сайт чтобы увеличить свои продажи, ему всё равно что там будет или чего не будет, зачастую он сам не знает чего хочет, и хочет чтобы ему показали, как может быть). Так вот, для сайтов, ориентированных на продажи и на эффективность - Битрикс (со стандартными компонентами) как нельзя лучше подходит. Для сайтов, ориентированных на что-то нестандартное (например, соц.сеть) Битрикс плохо подходит, поэтому нужно просто грамотно выбирать соответствующий инструментарий для решения соответствующих задач.
Хотя, сам то сайт - высоконагруженная социальная сеть, на которой используются только стандартные компоненты, так что ......
По воле случая попал в интересный проект, при котором нужно было очень быстро разворачивать много сайтов на Битриксе, по 40 сайтов в месяц (да, это так), имея в штате всего три php-разработчика (двое из них - совсем начального уровня, абсолютно без знания Битрикс, и с опытом в программировании на php до одного года, ну и третий - ваш скромный слуга). При этом имелся довольно солидный штат менеджеров в 25 человек, который обеспечивал хороший поток новых сайтов на холодном обзвоне. Задача была простая - если за два месяца удастся наладить производство - то тогда всё отлично, и эта штука будет жить, если нет - то тогда инвестированные денги заканчиваются, нечем платить зарплату и аренду, и приходится расходиться. Решил попробовать, хоть и рискованно что может не получиться, но зато весело, и всё только от тебя зависит. Скажу сразу, таким трудоголизмом как в те два месяца - я никогда в жизни так не работал. Бывало, конечно, когда нужно подзаработать брал подработку и работал до 4-х ночи, при этом на 9 утра идя на работу, но в таком режиме работал максимум неделю, после этого все выходные отсыпался. Но не в этом случае, тут у меня такой раш продлился более двух месяцев, но результат стоил того.
Так вот, идея, которую я хочу поделиться - состоит в том, что на стандартных компонентах можно быстро и много делать довольно хороших сайтов.
До недавнего времени, я был убежденным сторонником разработки на своих компонентах, все проекты, которые я делал (на фирме или на фрилансе) были написаны исключительно на одном компоненте, в файле result_modifier.php которого я добавлял требуемую логику, выбирая из базы только нужное, скурпулезно оптимизируя запросы, и получал вылизанное идеальное решение, работавшее максмально быстро, насколько это возможно в Битрикс. На написание подобного кода иногда уходили дни или недели, но времени было достаточно, фирма была большая (свыше 1500 человек), я был одним из сотрудников, который мог получать месяцами зарплату, и никто в другом отделе, или даже непосредственный руководитель - не знал чем я занимаюсь. Это было отлично, я мог писать сложнейший навороченный код, оптимизировать и писать прикольные штуки. Но, потом, когда понял, что способен на большее и хочется полнее реализовывать свои возможности, захотелось идти дальше, и ушел в этот новый проект. Здесь всё обстояло по другому, каждый день был на вес золота, и дополнительные пару часов, которые у меня выдавались вечером для программирования, когда я отключал аську и одевал наушники, были для меня невероятно ценны, так как можно было успеть запрограмить новый важный фукнционал.
Но понятно, что самому всё не сделаешь, нужны были помощники, на которых можно переложить неинтересную или механическую работу. При этом нужно было обеспечить им максимально четкие и простые инструкции, с которыми они бы создавали большое число сайтов. Сделал "простенький" конструктор, который создавал сайт с помощью заготовки, пару вариантов для выбра дизайна, парсер для перегона контента и с других сайтов, мастер настройки , параметров и доступов, и вперед. Вначале для меня было психологически трудно поверить, что за день можно сделать хотя-бы 4 сайта, так как до этого средний срок на создание сайта средней сложности был в лучшем случае пару месяцев. Но тем не менее, это возможно. Имея в штате дизайнеров, которые рисуют типовые дизайны за два-три дня (с четким набором бизнес-требований как можно и как нельзя рисовать), верстальщиков (либо фрилансеров) которые этот шаблон за день-два сверстают, и программистов, который натянет сайт на типовые компоненты за пару часов, можно на потоке спокойно выпускать по несколько сайтов в день.
Так вот, к чему я веду, если бы каждый компонент и каждый функционал писался индивидуально (даже имея примеры кода с прошлых сайтов), то всё равно это было бы долго. Если программист будет делать сайт больше дня, или если будет делать что-то слишком нестандартное, то на него может навалиться гора незавершенных сайтов и бесконечных доделок, поэтому всё должно быть просто и быстро, и надежно чтобы в последствии к этому не возвращаться, и чтобы кто-то другой мог доработать код первого программиста. Так как времени на обучение небыло, было решено всё делать на стандартных компонентах, в большинстве случаев программисты правили только шаблоны (этому научиться довольно просто, имея базовые знания html+php), и поняв, что такое компоненты, и что такое инфоблок. Задача предельно простая, добавляешь на страницу компоненты (меню, соц. закладки, поиск, форму обратной связи, хлебные крошки, новости, простенький каталог товаров), добавляешь включаемые области, слайдер, пару if-проверок в одном шаблоне (для главной и внутренних страниц), и всё, простенький сайт-визитка готов принимать своих первых посетителей. Так же имелся штат контент-менежеров, которые довольно лихо эти сайты наполняли, для них обучение проходило вообще быстро, так как документацию никто из них и не подумал открывать, было достаточно им хорошенько , оставив возможность менять только то, что нельзя поламать), и кинуть их на амбразуры. Я им оставил возможность менять только css-код шаблона (и то, не весь, а вынес его в отедльный файлик, и дал доступ только на него, через админку Битрикса), чтобы они могли переопределять стили, а так же имели доступ на вставку яваскриптов, и редактирование включаемых областей.
Но вернемся к программистам, тут самое интересное. Как-то на одном сайте мне нужно было сделать фотогалерею, всё как положено, на разделах и элементах, элементы строятся и подставляются в верхее выпадающее меню, автоматическое подставление фоновой картинки на основе первой картинки раздела, слайдер, увеличалка, и тд и тп. И сделать это нужно было буквально за пару часов, так как к концу дня в офис приезжал клиент, смотреть уже готовый сайт, и если бы он ему понравился - платил сразу деньги. Если нет - уехал бы и забыл бы про сайт (такой вот капризный клиент), но интересен сам челендж. Готового кода именно под этот случай у меня небыло. Вначале подумал, возьму, напишу код для выборки элементов, запихну его в menu_ext, напишу компонент каталога и тд. Но потом понял, что во первых, на это нет времени, а во вторых, потом этот код после меня будет дорабатывать программист-стажер (когда клиент захочет улучшение и развитие дальше), а времени рассказывать что это такое, и обучать его, опять нет. Решено, возьму компонент bitrix:menu.sections и положу его в menu_ext (вместо самописного кода), прикручу стандартные bitrix:catalog, со своими монстрообразными bitrix:catalog.sections и пусть себе крутится. Вначале для меня это было психологически сложно, как так, куча лишних запросов, неоптимальное кеширование, куча лишних файлов шаблонов, которые не используются (а просто копируются при копировании шаблона bitrix:catalog "за компанию"). Но выхода небыло, сделал. Действительно, быстро, просто, эффективно, хоть и слегка говнокодно (или, точнее сказать, не оптимально по производительности).
Но потом я решил посмотреть на это с другой стороны. А действительно ли это не производительно? Сайт посещать будет от силы 100 человек в день (если 500 - ну вааще супер), но даже при такой нагрузке время генерации страницы мизерно мало (0.01 сек или что-то такое), так как быстрый мощный хостинг. К слову о хостинге, решил не париться, взять shared-хостинг одного из битрикс-хостинг-партнеров, в котором удобная админка, легко добавлюятся сайты, легко нарастить производительность, легко передать сайт клиенту в случае если он решит дальше сам сопровождать сайт, относительно надежный, и что самое интересное - стоит копейки. Называть его не буду, думаю все и так знают какой самый популярный российский хостинг для битрикс-сайтов я имею ввиду, и который в последние годы хоть и испортился, но свою задачу по очень быстрому и очень недорогому хостингу - довольно успешно решает.
Так вот, время, которые я (или другой программист) потратили бы на оптимизацию кода, кеширования и пр, стоит в десятки, а то и в сотри раз больше, чем банально выделить дополнительное место под файловый кеш, которым так нещадно обрастает Битрикс (ну и, конечно, не забыть поставить автоочистку кеша раз в пару месяцев по крону, чтобы совсем не зарос), и банально докупить серверных мощностей. В наш цифровой век стоимость выходит действительно смешной, и как я вижу, дальше она только уменьшается. Даже тот-же Google использует в своих дата-центрах большое количество простеньких серверов. Более мощный сервер или больше дискового пространства - стоят реально на несколько порядков ниже времени работы программиста, это факт. Решающем показателем эффективности является время, чем быстрее сделал, тем больше заработал.
Здесь я не говорю про говнокод, как в примере когда , у нас такого нет, всё делается строго, на компонентах и в рамках четкого следования иделогии Битрикс (все сайты проходят монитор качества, это так же было одним из условий). Но, единственная ложка дегтя - делается это всё неоптимально по запросам и лишнему коду. Ну вот, взять хотя-бы компонент bitrix:catalog, и фотогалерею, сделанную на нем. Зайдя в параметры комопнента видим - типы цен, сравнения товаров, и прочую чепуху, зачем это в фотогалерее? Правильно, не зачем, но клиент не будет заходить в настройки, и программист не будет (ну, может, разок, на этапе программирования), и еще может быть еще разок, когда нужно будет что-то подправить. Конечно, поплюется, , поставит нужную галочку, но оно будет работать, и будет работать так, как нужно, и галочка (например, показывать элементы подразделов) там будет всегда, она знает что она там есть, и он её нажмет, а не будет писать свой код для выборки в api, тратя на это драгоценное время (жизнь).
Дальше больше. Сайты-визитки, конечно, хорошо, но возьмем магазины. Большинству представителей мелкого бизнеса нужен магазин чтобы быстро начать продавать, а они совсем не бум-бум в интернет-технологиях, но знают что Битрикс это круто, и хотят на нем магазин, и готовы платить, только бы им сегодня уже дать магазин, прикрутить простенький контекст, чтобы они ринулись увеличивать свои продажи. В магазине уже сложнее обойтись без стандартных компонентах, и наоборот, здесь они раскрываются во всей своей красе. Я бы не рискнул писать свои компоненты оформления заказа или компонент последних просмотренных товаров, или лучших продаж, или отзывов, или козрины. Конечно, хорошо когда под рукой есть готовые наработки, или свои компоненты корзины или отзывов, но их написание с нуля занимает прилично времени, и что еще важно - их сопровождение и постоянный допил. А так - этим допилом занимается сам Битрикс (хоть и редко, но бывает), но тем не менее это всё работает. Пусть отзывы и одноуровневые (и зачем-то на модуле форума), пусть на каждый просмотр товара делается апдейт-запрос на обновление счетчика просмотров, пусть корзина делает тучу лишних проверок, но всё это сможет подключить программист без опыта работы с минимальными трудозатратами, и даже то-т же фильтр лучших товаров вполне может быть реализован на bitrix:catalog.top и вполне нормально и быстро работать, как для штатного компонента.
Конечно, идеально бы если бы разработчики Битрикс прислушались и добавили поддержку , котором , тогда бы необходимость кастомизации штатных компонентов была бы еще меньше (фактически отпала), а если еще и $arParams (пусть даже не явно выведенных в параметрах компонента, но присущствующих в компонентах, чтобы разработчик мог их пользовать в нужный момент), то вообще бомба. Причем, я так смотрю, что идея работы только на стандартных компонентах далеко не нова, и многие продвинутые разработчики в курсе этой фишки, и , если проект с посещаемостью до тысячи человек в день. А то и больше.
Резюмируе вышесказанное, стандартные компоненты довольны круты, если правильно их готовить.
Плюсы:
- значительно сокращается время на обучение разработчиков
- наличие готовой докуменации
- наличие готового функционала (каталог, новости, отзывы, рейтинги, сравнение, корзина, лучшие товары, карта проезда, соц. кнопки и тд)
- довольно высокая функциональность через настройки без программирования
- идеологически просто дорабатывать проект разными программистами
- заказчику понятнее что это компонент "список новостей", а это компонент "каталог", чем если бы это был один компонент
Минусы:
- неоптимальное количество запросов, возможна более низкая производительность на высоконагруженных проектах
- невзоможность применения на сайтах с нетиповым функционалом
Первый минус - возможное снижение производительности за счет неоптимального числа запросов - будет проявляться только на действительно высоконагруженных проектах, где обычным наращиванием серверной мощности уже не обойтись. И то, этот лимит довольно далеко, так как с точки зрения эффективности бизнеса - дешевле докупить серверной мощности, чем платить за часы разработчика. Но мне пока что сложно представить, чтобы сервер ложили обычные компоненты вроде bitrix:catalog.section или bitrix:catalog.element. Да, они чуть медленнее, но не настолько, чтобы ложить сервер, скорее это только моральный дискомфорт с точки зрения разработчика, что его компоненты вытаскивают лишние данные на каждом хите (например, данные о разделе), когда нам нужен только список элементов, но на деле это практически не заметно, и банальные настройки конфигурации сервера влияют на производительность в разы выше и существеннее, чем лишняя выборка в компоненте.
А сайты с нетиповым функционалом - на то и нетиповые, для них проще написать один раз свой персональный компонент, сделав впоследствии этот компонент типовым, и тиражировать его на остальных сайтах уже как типовой компонент.
Ну, и если сайт совсем уже нетиповой - то конечно да, стандартным компонентам здесь не место, но возможно, что тогда и Битрикс выбрали не совсем правильно, лучше уж запилить это всё на каком-нибудь Zend Framework, и не плеваться на отсутствие недостающего функционала. Битрикс - это коробочный продукт, предназначенный для коробочных сайтов, иногда проще взять коробочного клиента, или переубедить его, что ему нужен коробочный продукт на котором будет такой-то раздел с новостями и такой-то функционал отзывов или рейтинга, вместо того чтобы вступать в дискуссию и идти на поводу, допиливая что-то нестандартно-индивидуальное, на что Битрикс с никак просто не способен. Здесь проще взять другой инструмент, и не рубить бревна лобзиком (или забивать гвозди микроскопом), а просто грамотно убедить, что такое инструмент для продаж (по большему счету заказчик заказывает у вас сайт чтобы увеличить свои продажи, ему всё равно что там будет или чего не будет, зачастую он сам не знает чего хочет, и хочет чтобы ему показали, как может быть). Так вот, для сайтов, ориентированных на продажи и на эффективность - Битрикс (со стандартными компонентами) как нельзя лучше подходит. Для сайтов, ориентированных на что-то нестандартное (например, соц.сеть) Битрикс плохо подходит, поэтому нужно просто грамотно выбирать соответствующий инструментарий для решения соответствующих задач.
Хотя, сам то сайт - высоконагруженная социальная сеть, на которой используются только стандартные компоненты, так что ......
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
