Pull to refresh

Comments 40

Почему нет варианта "не использовать битрикс совсем"?
Я сталкивался со случаями, когда интернет-магазин было проще написать с нуля на Yii2/Laravel, чем перепилить битрикс под задачи заказчиков.
UFO just landed and posted this here
Статья в первую очередь направлена для битриксоидов. А магазин можно поставить на чем угодно если есть готовый инструмент, а вот на счет проще с нуля поспорил бы. При работе с битриксом, есть много чего интересного и полезного, тут не поспоришь, чаще всего запросы заказчика покрываются стандартной сборкой битрикса и достаточно только настроить компоненты и сверстать шаблон. А вот когда задачи отходят от возможностей функционала стандартных компонентов, тогда возникают сложности.
Кого вы называете "битриксоидами" — пользователей или создателей?

Если первое, то я ничего конкретного в статье не увидел, что можно было бы применить на практике.

Если второе, то они всё, на самом деле, прекрасно понимают. Если посмотреть их выступления и почитать статьи, становится понятно, что это реальные профессионалы и они понимают, как должно быть. Главная проблема Битрикса — огромный технический долг, который с каждым релизом только увеличивают, вместо сокращения. А отказ от полного перехода на новое ядро, который изначально планировался, окончательно меня убедил, что из этой ямы им уже никогда не выбраться.
Для разработчиков, я думаю нет смысла писать на хабру какие то послания создателям.
Это концепт. Рекомендация того как распределить данные между структурными частями системы. Конкретный код, возможно, будет в другой статье.
Переход идет, и было понятно изначально, что он не будет не быстрым не простым, интернет магазин перевели на новое ядро, есть куча негатива, но это уже данность, все новое пишется сразу на новом ядре.
было понятно изначально, что он не будет не быстрым не простым

Денис, извините, я поленюсь искать информацию на форуме, я уже даже не помню, в каком году обещали выпустить это новое ядро, но:

  1. Оно позиционировалось как "трудно, но выполнимо". В итоге через год после обещаной изначально даты релиза выпустили что-то, но совсем не в том виде, в котором планировалось изначально.
  2. У этого нового ядра нет чётких границ. Может, я просто перестал держать руку на пульсе, но когда мне понадобилось недавно сделать небольшой модуль, я так и не смог найти новые объекты, в которых по планам должны были лежать Request и Response. Я банально не нашёл, можно ли средствами ядра json отдать. Новые компоненты пишутся на классах, их можно расширять? Если новые компоненты пишутся просто с использованием новых классов и ORM, то этого совершенно недостаточно.

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

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

Если вы общались только со студиями которые для ускорения пихали всю бизнес логику в код стандартных компонентов, то это говорит только о вашем личном опыте и не характеризует систему в целом.

А говнокод есть везде. Если вам не хочется переписать код, который вы писали год назад, значит вы перестали развиваться.
  1. Я в данный момент работаю с битриксом, и очень часто встречаю таких персонажей, так что это не ярлыки, а грустная правда;
  2. Модули из коробки — не совсем бизнес логика. Точнее не все модели из коробки, это true MVC. Если вы писали сами, то вы как угодно могли писать компоненты и модули, а моя статья направлена на то, что есть изначально. Я считаю что размещение логики в компонентах — это в порядке вещей, собственно данному мнению посвящен пункт "Битрикс. HMVC"
  3. Откройте стандартные компоненты.
Битрикс сейчас переходит на новое ядро, соответственно стандартные компоненты также постепенно переписываются (в основном это касается магазина и всего что с ним связано).

Многие старые компоненты не трогались годами и код там устарел, но работает. Но это не повод тыкать туда пальцем и верещать про говнокод.

Стандартные компоненты это всего-лишь набор примеров того как можно решить задачу. Если они кого-то устраивают — можно пользоваться ими, но лучше написать своё.
Вот с первым вашим комментарием я согласен — на Битриксе можно писать хорошо, если делать всё самому.
А вот с этим поспорю.

  1. "Переходит на новое ядро" Битрикс уже несколько лет. И никогда до конца не перейдёт. Добавили какой-никакой ORM, вот и все значительные изменения. Говорили про новый порядок загрузки страницы, но его так и не внедрили, а это самое главное, что должно было произойти.
  2. Стандартные компоненты переписываются, чтобы поддерживать новый функционал, а код в них всё так же плох, они всё так же нерасширяемы.
Так я и не писал что битрикс хорошо осуществляет этот переход. Мягко говоря, они задолбали тянуть. Ни документации, ни внятных примеров. Только видосики и статьи от интерволги — это несерьёзно. Но больше всего смущает что это самое новое ядро еще не устаканилось и переходить на него сейчас опасно, ведь всё еще может измениться.

Я уже написал что стандартные компоненты это лишь примеры. Там по стандартам кодирования видно что писали их разные команды в разное время, нет смысла на них циклиться. В любом случае, они слишком избыточны для решения конкретных задач.
Стандартные компоненты это всего-лишь набор примеров того как можно решить задачу. Если они кого-то устраивают — можно пользоваться ими, но лучше написать своё.

Да, они именно так и позиционируются, но есть одна проблема — стандартные компоненты часто диктуют, каким должно быть ядро, а не наоборот.
Создаётся впечатление, что некоторые модули писались так: создавалась вёрстка, под неё подгонялись компоненты, а потом код из них выносили в модуль.
В итоге, ядром в отрыве от компонентов пользоваться вообще нельзя. Яркий пример тому — модули CRM и Техподдержка, у меня каждый раз волосы на голове шевелятся, когда приходится в классы ядра ходить. Особую пикантность добавляет то, что по CRM документации вообще нет.
Техподдержка это вообще печаль =( Мы из-за неё вообще и вляпались в битрикс когда-то. Этот модуль не обновлялся уже лет 8 не меньше. Были там какие-то косметические изменения, но не более того.

Я в битрикс писал вопросы, планируют ли они его обновлять. Но они считают что там всё зашибись.
В итоге, получается, что плюсов у Битрикса нет, кроме того, что "оно как-то работает". Мне когда с ним приходится работать, я банально не получаю удовольствия от ковыряния в этом вот всём.
Мы сделали на нём несколько довольно крупных вещей, но на каждом этапе вместо того, чтобы помогать, система вставляла палки в колёса.
Я бы резюмировал это так: Битрикс неплохая CMS, но очень плохой фреймворк, потому что задачи фреймворка он не решает.
CRM мне кажется вообще вещь в себе. Там чтобы хоть что-то кастомизировать надо ведро слез наплакать. Но это еще не значит, что модули не являются/не должны являться реализацией модели. Все же модель это модуль, а не просто ИБ.
Что же до документации по CRM… Вы же видели ее код и архитектуру. Проще новую CRM с документацией написать чем документацию к этой.
"Если вам не хочется переписать код, который вы писали год назад, значит вы перестали развиваться."
В точку!
Битрикс позволяет быстро развернуть рабочее решение, если действительно функционал системы покрывается стандартными средствами. Не более. Если же есть потребность что-то программировать, извините, начинает тошнить. 21 век, а там все global $APPLICATION, $USER, $DB… Да и стандартные компоненты убогое г — открываешь какой-нить sale.order.ajax и видишь простыню на 2к строк…
Напишу, за что поставил минус. Если убрать из текста неуместные в рамках статьи нападки на Битрикс и прописные истины вида "что такое MVC", то в ней останется только "прикольно было бы в Битриксе реализовать HMVC". И всё. Вы даже не попытались свою идею реализовать, чтобы проверить работает она или нет (ну или в статье об этом не написали, что равнозначно).
Опять повторюсь — это концепт. Сырая реализация есть, но она сырая. А пример реализации я планировал в более масштабном примере выложить. Так что в скором времени ждите, а вообще данной статьей я планировал привлечь критические коментарии косательно самой архитектуры, а не холивар по поводу того что битрикс новое ядро уже несколько лет разрабатывает…
Веселенько. А описание структуры это не архитектура? Или в вашем понимании архитектура это код? В статье расписано архитектура и по сути нет только программной части, реализации этой самой архитектуры.
То, что вы представили, на мой взгляд, не архитектура, а концепт — два абзаца и картинка. На мой взгляд, это не тянет на отдельную статью, о чём я и написал.
У меня есть ощущение, что сами разработчики в качестве Service Layer используют class.php, а «контроллер» в component.php, иначе как объяснить недоразумение bitrix/catalog.smart.filter?

P. S. Вопрос на засыпку, кто знает как определяется класс используемый в class.php?… кто не знает см bitrix/modules/main/classes/general/component.php:__getClassForPath
Сейчас специально вот подумал чего бы такого для примера открыть. Берем шаблон catalog.bigdata.products и что мы видим? Ни чего не видим, по тому что кровь и слезы застилают глаза. Неужели кто-то в здравом уме поставит такой код в нормальный магазин?
Посоветуйте нормальных (правильных) ресурсов по разработке на битриксе.
Потому как
 print_r( $arResult ) 
даже в официальном руководстве и курсах Специалиста — это адЪ.
Тем, кто решит отправить меня к официальной документации, советую посмотреть про CGuest — класс существует, а документация никак не соответствует функционалу.
Там всё не лучше той документации. Такое ощущение, что кроме отдела маркетига, никто ничего там просто не умеет.
Так что, лучше не ищите не существующих хороших ресурсов по разработке на битриксе, а используйте более продуманные инструменты.
К сожалению, чаще всего Б достается в наследство. Убедить руководство перехать с Б на что-то более понятное — маловероятно.
Опять же, дурацкие мифы о легкой интеграции с 1С, легкой катомизации (читай «костылизации») — это все работает на продажи Б.
Посоветуйте нормальных (правильных) ресурсов по разработке на битриксе

http://symfony.com/ =)
это на случай если заказчик не будет доволен сборкой битрикса из коробки, по мне так кроме этих случаев его вообще не стоит использовать
Говно ваш битрикс. Проклинаю тот день когда согласился "набросать из готовых компонентов магазинчик".
Самое смешное, что самому битриксу какой год начхать на критику, ровно как и всем кто делает на нем деньги — им просто по барабану, они давным давно даже не пытаются вступать в беседы так как на что это влияет?)))
Проблема в том, что все это теплое-ламповое комьюнити застыло где-то в начале 2000-х, и они продолжают писать модули с компонентами на императивный манер. Если качество продукта таково что купив его тебе нужно все переписать заново, то зачем оно надо? Поняв это адекватный народ переходит на другие системы. А если кто то предпочитает делать вид, что не видит как горит их собственный дом — это их проблема.
В каждой задаче есть смысл. В задаче битрикса — обслуживать желающих желательно во всей производственной цепи. Это самая главная и основная цель любого идеального бизнеса. Судя по их развитию, они не испытывают проблем с тем кому там что-то не нравится.
Им просто плевать про том где они застряли, какой у них код. Что у кого-то там не получается переписать. Бабло течет рекой, речи Рыжикова слаще меда.
Все рассуждатели о качестве продукта — просто лузеры, с точки зрения битрикса. Им на это вобще по барабану)) Сколько фирм по стране, сколько людей с этого имеют бабло, продукт просто уникален)) Все равно платит клиент за все в конечном итоге.
Я тоже был мягко говоря удивлен. когда просто никогда особо не копаясь в api, взял событие обновления корзины — и попал сразу на багу. Просто бац — "да, это баг, подтверждаем." Ну и что если я говном изолью им или куда то на форум хабр… плевать им что там магазин из за этого перестал работать так как он работал на старом ядре, когда эта бага не проявлялась, ну… с битриксом все ясно. Либо в секте которая кормит, либо ну… ну где же заменители битрикса...
Не знаю за что вас минусуют (скорее всего за то что коммент на странице которая содержит слово битрикс), но по ссылке просто передергивания, субъективизм, а местами и откровенная ложь.
Шило на мыло менять — та еще радость.
так за шило бабло платить, а за мыло не сильно. Раз шило на мыло — зачем платить больше?)
Sign up to leave a comment.

Articles