Malezha
Проверенные
- Сообщения
- 132
- Реакции
- 75
- Баллы
- 5,525
Все ниженаписанное является только моим мнением и не претендует на прописную истину ?
В бородатые времена XenForo 1.4 я познакомился с этим чудесным продуктом как пользователь и был потрясен: огромное количество уже встроенных возможностей и бесконечный потенциал для расширения. А насколько тут все просто и интуитивно, установка плагинов, тем - двумя кликами в админ-панели и никакой мороки с доставкой и распаковкой архива на сервере, и точно такое же простое обновление всего этого богатства. Лучший движок для сообщества одним словом!
Потом я уже узнал (когда понадобилось расширить функционал) что под капотом там Zend Framework, хоть и первой версии (на тот момент она уже была устаревшей), но для меня показывало, что разработчики XenForo не занимаются изобретением велосипеда, а делают свой продукт, хоть и с использованием не самых новых инструментов, но тех, где они профессионалы. В те времена Composer еще не был де-факто стандартом, хотя уже стал полезным инструментом, PSR-0 воевал с PSR-4, а Laravel все еще добавлял не косметические изменения новые релизы, а XenForo был в духе того времени (хотя сейчас стало ясно, что уходящего), так что проблем с дописыванием своего функционала возникло не много.
Время шло, Composer стал стандартом, PHP-Fig стали принимать не только рекомендации по стилю написания кода, но и рекомендации по контрактам (интерфейсам) самых часто используемых компонентов в фреймворках, которые в свою очередь стали поддерживать и крупнейшие игроки. И вот выходит XenForo 2. У меня тогда не было нужды в его использовании, и я пропустил большую часть подробностей, хотя краем уха и читал, что теперь это совсем другой продукт, что разработчики не побоялись сломать обратную совместимость, теперь XenForo современный и отвечающий текущим стандартам серьезных приложений, чуть ли не CMF для сообществ. С тех пор я прибывал в заблуждении. Конечно, небольшое подозрение закладывалось, когда никто не трубил про переезд на новую версию Zend Framework или смене фреймворка на Symfony. Абсолютной правдой будет то, что я сам себя ввел в это заблуждение.
В итоге только сейчас я добрался до XenForo 2. Отличный продукт, плохой код. Да, вот так сразу и это будет мое полное мнение. Ах, аргументы, да зачем они вам нужны? Вы же не хотите, чтобы у вас горело от моих слов, как горит у меня от XenForo? Хотите? Ну тогда читайте дальше.
Мое первое заблуждение по поводу XenForo 2 состоит в том, что я поверил, что продукт использует фреймворк. Только не подумайте, что я не вижу свою жизнь без фреймворков, но я и не болею синдромом Тараса КТЛ: если вам нужен простой блог, то не нужно тащить Symfony с богомерзкой Doctrine, это инструменты для проектов с куда более сложной бизнес-логикой, есть Wordpress или MaxSite CMS. Я прекрасно понимаю, что ни один фреймворк не является панацеей - это только инструмент, но этот инструмент полностью покрыт тестами, имеет хорошую документацию, огромное количество расширений и развитое сообщество разработчиков. И это я не только про Symfony, но и про любой другой «крупный» фреймворк. Существует только одна проблема - из-за широких возможностей к расширению функционала необходимо платить быстродействием. Это очень серьезный аргумент если бы не одно «но»: все современные фреймворки представляют из себя сконфигурированный набор компонентов и именно в конфигурации, а также возможности её менять идет падение скорости. Можно самостоятельно собрать необходимые компоненты и сделать свой инструмент (собственно так и родился Laravel из Symfony), а можно написать yet another framework, но зачем?
Я открываю XF\Http\Request и вижу упрощенный Symfony\Component\HttpFoundation\Request, я смотрю неймспейс XF\Mvc и вижу компонент Symfony Routing и кусочек HttpKernel. И так код весь XenForo. Что же в этом плохого? XenForo не придерживается PSR. И тут начинается холивар на тему что это всего рекомендации и вообще все PSR с интерфейсами делают фреймворки одинаковыми. Но плохо ли это? У меня есть библиотека, которая в процессе роботы не прочь кэшировать промежуточные результаты для ускорения последующих итераций работы. Когда я её начал писать, предполагалось, что она будет использоваться вместе с Laravel и я сделал зависимость от Illuminate\Contracts\Cache\Repository, но чуть позже библиотека пригодилась и для проекта на Symfony. Конечно вы догадались, я переправил зависимость на Psr\SimpleCache\CacheInterface. Все так просто, потому что и Laravel и Symfony придерживаются PSR-16. Ну а XenForo использует компонент кэша от Doctrine. Конечно есть адаптеры, приводящие к PSR-6 и PSR-16, но их нужно установить, используя Composer.
Если фреймворки я и не считаю панацеей, то без Composer написание чего-либо длиннее 100 строчек кода для меня уже вызывает раздражение, потому что к хорошему привыкаешь. Composer хоть и является в первую очередь менеджером пакетов, без которых сейчас могут обойтись разве что фанаты чистого кода, он привнес не только упрощение в сравнении с PEAR, но и упорядочил целое семейство загрузчиков и объединил их. Теперь достаточно сделать require_once действительно только один раз и у вас все работало (после того как вы опишите правила загрузки в специальном файле). Отличный инструмент, который используется в XenForo 2, правда с парой небольших ограничений - файл с конфигураций автозагрузки и список зависимостей, а так же список установленных пакетов нам не дали (ну точнее не дали composer.lock, но почему то забыли про vendor/composer/installed.json). Объективной причины, я честно говоря не вижу, и то что dokuwiki/utf8 не пакет, а просто выдернутый из dokuwiki файл, который заставили прикинуться пакетом (и зачем то дописали что это написано для XenForo - vendor/dokuwiki/utf8/utf8.php, строка 8) слишком бросается в глаза что бы скрывать composer.json. Ну ничего, там дали для использования Composer при разработке плагинов, которые в свою очередь порождают другие костыли - носи все зависимости с собой (даже те, которые уже есть в XenForo). Да-да, необходимо обеспечить установку дополнений из архива прямо в браузере, но почему бы попытаться совместить оба варианта? «Для нас это не проблема» - сказали разработчики , вроде бы мелочь, но очень удобная.
Последним у нас идет очень веселая тема - тесты. Команда XenForo хоть и очень скрытная, но автотесты они конечно используют (я правда надеюсь), а вот как быть разработчикам плагинов? Всякие опечатки в строковых константах, динамический функционал и т.п. - ручное тестирование каждой возможности перед каждым релизом? Пока это единственный вариант.
Немного вводит в недоумение необходимость описывать мета-информацию (обработку событий, роутинг и т.п.) для плагина в админ-панели. Описывать все это в xml и json мало удовольствия - авто дополнения нет, приходится все время подсматривать параметры. Да и почему для описывания одного у нас xml, а для другого уже json? Писало два человека, один из которых обожает xml, а другой терпеть его не может? Вообще этим очень страдают комментарии к коду: в одном методе есть полноценный phpDoc, в другом чисто типизация, в третьем вообще нет комментариев и все эти методы идут один за другим. Да и в плане кодстайла порой вопросы «зачем» и «почему» возникают. Service Locator мимикрирует под di-контейнер, хотя никакого внедрения зависимостей не предусмотрено, как следствие - везде одна статика. С другой стороны, написали же свой Active Record, могут, когда хотят. Точнее, когда пишу код не джуны.
Если взять все описанное выше, то я просто докопался до мелочей, не более. Ведь пишут же непростые плагины, да и сам XenForo использует каждое второе сообщество, чего еще рядовому разработчику хотеть? Вопрос открытый, но с моей точки зрения, XenForo 1 занимал пустую нишу на рынке как раз потому, что был написан во времена уже сложившихся (де-факто) базовых стандартов проектирования и написания приложений на PHP и XenForo 2 мог развивать данное течение используя уже современные стандарты (в отличии от IPB и vBulletin плавающих в море легаси). Тот факт, что вторая версия полностью переписана на свою кодовую базу делает из продукта еще один фреймворк, вот только никому ненужный, ведь его нельзя использовать где-то еще (без костылей), да и не стоит из-за сомнительного качества кода. Неужели авторы XenForo боятся оттолкнуть писателей плагинов чуть более сложными паттернами, брать количеством дополнений, а не их качеством?
Наверное, стоит закончить брызгаться желчью и подвести какие-то итоги всему написанному: XenForo 2 лучший из виденных мною в нише продуктов для сообществ, но он мог быть еще лучше. Спасибо за прочтение, открыт к дискуссии и очень хочу услышать ваше мнение ?
В бородатые времена XenForo 1.4 я познакомился с этим чудесным продуктом как пользователь и был потрясен: огромное количество уже встроенных возможностей и бесконечный потенциал для расширения. А насколько тут все просто и интуитивно, установка плагинов, тем - двумя кликами в админ-панели и никакой мороки с доставкой и распаковкой архива на сервере, и точно такое же простое обновление всего этого богатства. Лучший движок для сообщества одним словом!
Потом я уже узнал (когда понадобилось расширить функционал) что под капотом там Zend Framework, хоть и первой версии (на тот момент она уже была устаревшей), но для меня показывало, что разработчики XenForo не занимаются изобретением велосипеда, а делают свой продукт, хоть и с использованием не самых новых инструментов, но тех, где они профессионалы. В те времена Composer еще не был де-факто стандартом, хотя уже стал полезным инструментом, PSR-0 воевал с PSR-4, а Laravel все еще добавлял не косметические изменения новые релизы, а XenForo был в духе того времени (хотя сейчас стало ясно, что уходящего), так что проблем с дописыванием своего функционала возникло не много.
Время шло, Composer стал стандартом, PHP-Fig стали принимать не только рекомендации по стилю написания кода, но и рекомендации по контрактам (интерфейсам) самых часто используемых компонентов в фреймворках, которые в свою очередь стали поддерживать и крупнейшие игроки. И вот выходит XenForo 2. У меня тогда не было нужды в его использовании, и я пропустил большую часть подробностей, хотя краем уха и читал, что теперь это совсем другой продукт, что разработчики не побоялись сломать обратную совместимость, теперь XenForo современный и отвечающий текущим стандартам серьезных приложений, чуть ли не CMF для сообществ. С тех пор я прибывал в заблуждении. Конечно, небольшое подозрение закладывалось, когда никто не трубил про переезд на новую версию Zend Framework или смене фреймворка на Symfony. Абсолютной правдой будет то, что я сам себя ввел в это заблуждение.
В итоге только сейчас я добрался до XenForo 2. Отличный продукт, плохой код. Да, вот так сразу и это будет мое полное мнение. Ах, аргументы, да зачем они вам нужны? Вы же не хотите, чтобы у вас горело от моих слов, как горит у меня от XenForo? Хотите? Ну тогда читайте дальше.
Мое первое заблуждение по поводу XenForo 2 состоит в том, что я поверил, что продукт использует фреймворк. Только не подумайте, что я не вижу свою жизнь без фреймворков, но я и не болею синдромом Тараса КТЛ: если вам нужен простой блог, то не нужно тащить Symfony с богомерзкой Doctrine, это инструменты для проектов с куда более сложной бизнес-логикой, есть Wordpress или MaxSite CMS. Я прекрасно понимаю, что ни один фреймворк не является панацеей - это только инструмент, но этот инструмент полностью покрыт тестами, имеет хорошую документацию, огромное количество расширений и развитое сообщество разработчиков. И это я не только про Symfony, но и про любой другой «крупный» фреймворк. Существует только одна проблема - из-за широких возможностей к расширению функционала необходимо платить быстродействием. Это очень серьезный аргумент если бы не одно «но»: все современные фреймворки представляют из себя сконфигурированный набор компонентов и именно в конфигурации, а также возможности её менять идет падение скорости. Можно самостоятельно собрать необходимые компоненты и сделать свой инструмент (собственно так и родился Laravel из Symfony), а можно написать yet another framework, но зачем?
Я открываю XF\Http\Request и вижу упрощенный Symfony\Component\HttpFoundation\Request, я смотрю неймспейс XF\Mvc и вижу компонент Symfony Routing и кусочек HttpKernel. И так код весь XenForo. Что же в этом плохого? XenForo не придерживается PSR. И тут начинается холивар на тему что это всего рекомендации и вообще все PSR с интерфейсами делают фреймворки одинаковыми. Но плохо ли это? У меня есть библиотека, которая в процессе роботы не прочь кэшировать промежуточные результаты для ускорения последующих итераций работы. Когда я её начал писать, предполагалось, что она будет использоваться вместе с Laravel и я сделал зависимость от Illuminate\Contracts\Cache\Repository, но чуть позже библиотека пригодилась и для проекта на Symfony. Конечно вы догадались, я переправил зависимость на Psr\SimpleCache\CacheInterface. Все так просто, потому что и Laravel и Symfony придерживаются PSR-16. Ну а XenForo использует компонент кэша от Doctrine. Конечно есть адаптеры, приводящие к PSR-6 и PSR-16, но их нужно установить, используя Composer.
Если фреймворки я и не считаю панацеей, то без Composer написание чего-либо длиннее 100 строчек кода для меня уже вызывает раздражение, потому что к хорошему привыкаешь. Composer хоть и является в первую очередь менеджером пакетов, без которых сейчас могут обойтись разве что фанаты чистого кода, он привнес не только упрощение в сравнении с PEAR, но и упорядочил целое семейство загрузчиков и объединил их. Теперь достаточно сделать require_once действительно только один раз и у вас все работало (после того как вы опишите правила загрузки в специальном файле). Отличный инструмент, который используется в XenForo 2, правда с парой небольших ограничений - файл с конфигураций автозагрузки и список зависимостей, а так же список установленных пакетов нам не дали (ну точнее не дали composer.lock, но почему то забыли про vendor/composer/installed.json). Объективной причины, я честно говоря не вижу, и то что dokuwiki/utf8 не пакет, а просто выдернутый из dokuwiki файл, который заставили прикинуться пакетом (и зачем то дописали что это написано для XenForo - vendor/dokuwiki/utf8/utf8.php, строка 8) слишком бросается в глаза что бы скрывать composer.json. Ну ничего, там дали для использования Composer при разработке плагинов, которые в свою очередь порождают другие костыли - носи все зависимости с собой (даже те, которые уже есть в XenForo). Да-да, необходимо обеспечить установку дополнений из архива прямо в браузере, но почему бы попытаться совместить оба варианта? «Для нас это не проблема» - сказали разработчики , вроде бы мелочь, но очень удобная.
Последним у нас идет очень веселая тема - тесты. Команда XenForo хоть и очень скрытная, но автотесты они конечно используют (я правда надеюсь), а вот как быть разработчикам плагинов? Всякие опечатки в строковых константах, динамический функционал и т.п. - ручное тестирование каждой возможности перед каждым релизом? Пока это единственный вариант.
Немного вводит в недоумение необходимость описывать мета-информацию (обработку событий, роутинг и т.п.) для плагина в админ-панели. Описывать все это в xml и json мало удовольствия - авто дополнения нет, приходится все время подсматривать параметры. Да и почему для описывания одного у нас xml, а для другого уже json? Писало два человека, один из которых обожает xml, а другой терпеть его не может? Вообще этим очень страдают комментарии к коду: в одном методе есть полноценный phpDoc, в другом чисто типизация, в третьем вообще нет комментариев и все эти методы идут один за другим. Да и в плане кодстайла порой вопросы «зачем» и «почему» возникают. Service Locator мимикрирует под di-контейнер, хотя никакого внедрения зависимостей не предусмотрено, как следствие - везде одна статика. С другой стороны, написали же свой Active Record, могут, когда хотят. Точнее, когда пишу код не джуны.
Если взять все описанное выше, то я просто докопался до мелочей, не более. Ведь пишут же непростые плагины, да и сам XenForo использует каждое второе сообщество, чего еще рядовому разработчику хотеть? Вопрос открытый, но с моей точки зрения, XenForo 1 занимал пустую нишу на рынке как раз потому, что был написан во времена уже сложившихся (де-факто) базовых стандартов проектирования и написания приложений на PHP и XenForo 2 мог развивать данное течение используя уже современные стандарты (в отличии от IPB и vBulletin плавающих в море легаси). Тот факт, что вторая версия полностью переписана на свою кодовую базу делает из продукта еще один фреймворк, вот только никому ненужный, ведь его нельзя использовать где-то еще (без костылей), да и не стоит из-за сомнительного качества кода. Неужели авторы XenForo боятся оттолкнуть писателей плагинов чуть более сложными паттернами, брать количеством дополнений, а не их качеством?
Наверное, стоит закончить брызгаться желчью и подвести какие-то итоги всему написанному: XenForo 2 лучший из виденных мною в нише продуктов для сообществ, но он мог быть еще лучше. Спасибо за прочтение, открыт к дискуссии и очень хочу услышать ваше мнение ?
