Послевкусие экосистемы Ruby (on Rails) или "мы любим ненавидеть PHP"

От переводчика:
Если вы PHP разработчик и поглядываете в сторону Ruby (on Rails), или же наоборот, вы Ruby разработчик и подумываете перейти на темную сторону PHP, то я думаю вам понравится этот перевод статьи "Ruby (on Rails) ecosystem bittersweet or «we like to hate PHP»".

Резюме:
Я хочу представить некоторые факты, а также и личный опыт, в доказательство того, что PHP это более жизнеспособное, конкурентное и слабосвязанное сообщество, чем экосистема Ruby. Я имею ввиду: производительность, синтаксис, аспекты кодинга, сообщество и поддержка инструментария.

Если вы хотите пропустить большую часть всей этой пустой тирады – то сразу же листайте до заголовка: “Главная часть начинается здесь...” Но я все же должен сказать это...

Что? Еще одна анти-RoR проповедь?

Да. Я начал собирать материалы для этого поста около 6 месяцев назад, и я в курсе всех последних дискуссий “за и против”, что происходят вокруг RoR. Главные это: "My time with Rails is up" и Rails has won: The Elephant in the Room. Я определенно не так опытен в RoR, чтобы рассказать что-то новое, чего не было бы уже сказано. Я просто хочу поспорить с Rails лидерами в web разработке.

[PHP] … разбитое на кусочки, независимое и изолированное сообщество... это один большой океан отделенных островков.

Как говорил AkitaOnRails (от переводчика: основатель блога про Ruby), это как всегда правда с одной стороны и не правда с другой. Дорогие рубисты, дайте мне показать вам мир близкого соперника – PHP. В Ruby лагере нет ничего особенного или уникального, чего мы не сможем найти в PHP.

Эволюция моего видения

Я вошел в Ruby мир только полтора года назад, после более 5 лет в PHP разработке. Я изо всех сил боролся. Была нелегкая миграция и адаптация. По воле случая я был выбран, чтобы построить Ruby (on Rails) команду разработчиков в MobiDev с нуля. С этого времени я был вовлечен в бурлящее обучение себя, и доведения до кондиции как новичков, так и уверенных середнячков Ruby разработчиков.

Вскоре я понял одну вещь: мир RoR с точки зрения хипстеров и “классных ребят” был немного приукрашен и преувеличен. Сегодня RoR не предлагает ничего лучшего чем среднестатистический PHP фреймворк, за исключением запуска фоновых задач из коробки.

Даже хуже - это подталкивает к некоторым решениям, которые “считаются вредными” даже в PHP. В основном это нарушения SRP и CQRS, поощряемые самим фреймворком. И, честно говоря, довольно большое RoR приложение это абсолютная магия, из-за Monkey Patching (незаметная подмена кода) и повсеместного добавления неявного поведения.

Только подумайте об одном SRP (принцип единственной ответственности) примере...

“Не из-за этого ли мы перестали писать на PHP?”

Извини Nick (ссылка на твиттер), я процитировал твою книгу (ссылка на книгу https://leanpub.com/trailblazer) и несогласен с этим утверждением. Я вижу, что много Ruby разработчиков любят ненавидеть PHP. Большинство из них никогда даже не видели ни единого кусочка реального кода на PHP, но “мой друг говорил мне… что это ужасно”. Или они видели Wordpress - самый популярный, но и самый мерзкий PHP код (в обнимку с архитектурой).

Я хочу заявить, что это ошибочное мнение в 2016 году. PHP сообщество имеет много интересных вещей, которые Ruby программисты пропустили мимо себя.

Только недавно я понял эту умную идею, которая в реальности выглядит довольно правдивой (для меня).

Простите, но я обязан добавить еще два теоретических параграфа про Ruby, до того как мы реально перейдем к PHP…

Это как домашнее насилие…

Реакция большинства Ruby разработчиков на предложение “взглянуть со стороны на RoR” напоминает мне поток сознания жертвы домашнего насилия. И что-то вроде Стокгольмского синдрома RoR зависимости.

Видеть это печально, но это правда. “Золушка” живет в холоде, страхе, и сложном, как ад, мире. Она влюбилась в очаровательного принца. Он потрясающий, понимающий ее с первого слова, делающий ее жизнь такой светлой, обещающий любить ее навеки и делать все что она не попросит…

Они поженились и переехали в его замок. И тут ее жизнь немного изменилась…

После нескольких совместных лет жизни, она не может сделать и шага без Его согласия. Более того, он может даже ударить ее, если бы она попыталась это сделать. Она должна сообщать о каждом своем шаге и соглашаться с Его стилем жизни. Она уже забыла какова была ее жизнь раньше, без его сверх опекунства и содействия прислуги. Все люди, которых она знала и с которыми общалась - это в похожем положении жены соседей тиранов. И все чаще она слышит от него: “Даже не думай покидать меня! Никому ты не нужна кроме меня. Ты не сможешь ничего сделать сама!”

Замкнутый круг востребованности

“Ничего - вот ответ. В Ruby нет программных средств, чтобы удержать тебя от использования “опасных инструментов” для разрезания Гордиевых узлов, при необходимости. Мы просто развиваем чувство надобности использования этих инструментов, с помощью договоренностей и через обучение. А не запрещаем “опасные инструменты” на кухне, настаивая на том, что всем необходимо использовать ложки для нарезки помидоров.”
© DHH, "Provide sharp knives"

Обучение. Действительно ли Rails учит нас?

Когда разработчики начинают использовать Rails, то учатся быть только с Rails. Не могут сделать и шага без него. Не могут различить, где чистый Ruby и где monkey-patching Rails. Они не могут увидеть что-то лучшее, да они и не хотят что-то лучше. Не могут сделать даже тонкий SQL запрос без ActiveRecord. Производительность? Кого это беспокоит? Заказчики уже пойманы на Rails маркетинг и “большое сообщество разработчиков”. Они требуют приложения выполненные с Rails. Разработчики используют Rails, потому что это очень легко (не просто!) и заказчики также хотят именно Rails. Как только ты начинаешь задумываться о соскакивании с Rails иглы - то понимаешь, что тебе некуда идти. Заказчики боятся делать не Ruby on Rails приложения, потому что они “не смогут найти не Rails разработчиков”. И разработчики боятся спрыгнуть с Rails, так как “они не смогут найти не Rails работу”. Порочный круг. И уже совсем не важно, предложение рождает спрос или наоборот.

В PHP мире нет подобной проблемы. Заказчики даже порой не требуют какой-то определенный фреймворк. Разработчики вольны выбирать или предлагать то, что они знают лучше, и что подходит лучше к определенным требованиям. Да, есть множество Rails подобных фреймворков, но также есть большое количество фреймворков с другой философией.

╰( •̀ε•́╰) Главная часть начинается здесь…

Эволюционирование и производительность

В 2005 году PHP достиг “зрелости” в ООП - вышла 5.0 версия (с версии 3.0 была представлена очень ограниченная версия ООП). Определенно, довольно долгое время RoR имел существенное преимущество перед PHP, изначально имея хорошую поддержку ООП.

Но с 2012 года, с выходном новой версии 5.4, PHP получил массивный толчок вперед: HipHop VM от Facebook и рост экосистемы. Сегодня, с версией 7.0 и HackLang от Facebook, PHP получил 2х кратный прирост производительности и существенное уменьшение потребления памяти. И теперь, PHP, уж точно не медленнее Ruby 2.x.

Самое большое достоинство PHP, это независимость производительности приложения от Dev или Prod окружения. PHP не требует перезагрузки классов (для обеспечения актуальности кода). Только debug расширение добавляет некоторый штраф к скорости. Но Prod окружение не может выкинуть вам неожиданное поведение, потому что, по-умолчанию, оно ничем не отличается от Dev.

Будущее PHP выглядит безоблачным, благодаря таким корпорациям как - Zend и Facebook. Они постоянно работают над улучшением PHP, делая его быстрее и лучше.

А что насчет будущего Ruby? Множество альтернативных воплощений с туманными перспективами.

Сообщество

Помимо корпораций, которые контрибьютят в PHP, еще также существует реальное сообщество - PHP FIG (Framework Interop Group).

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

Здесь сотрудничают ребята из большого количества влиятельных PHP проектов (да, порой мы очень громко ссоримся) и предлагают хорошие рекомендации для PHP стандарта (PSR). И сообщество действительно перенимает и следует их рекомендациям.

И теперь, благодаря PHP FIG, у нас имеется два, очень важных, стандарта: Стандарт Написания кода (Coding Standard) и Стандарт Автозагрузки посредством Пространства Имен (Namespaces Autoloading Standard). Очень тяжело переоценить, насколько важны эти вещи для современного PHP. Это позволяет комбинировать различные проекты и библиотеки в неконфликтующий код.

Серьезно, я не видел ничего подобного в мире Ruby, кроме вездесущей диктатуры.

Пакеты

Да, Bundler и Gems в Ruby были невероятно крутыми в свое время, и тогда PHP был ужасен со своим ручным копированием кода. С 2012 года PHP обзавелся Composer, спасибо PHP FIG стандартам за это. Такое достижение помогло управлять пакетными зависимостями и автозагрузкой кода “по горячему”.

В PHP нет потенциальной проблемы коллизий среди пакетов и проектов, в которых они используются, потому что каждый новый проект скачивает свой уникальный набор библиотек.

Автоподгрузка классов базируется на Пространстве Имен. И на практике это работает лучше, чем константная автозагрузка в Rails c Ruby модулями. В PHP все Composer пакеты имеют уникального вендора (Namespace) и за счет этого легко отследить что код уже был загружен. Действительно, в Rails у меня много проблем с этим, и совсем нет - в PHP.

В PHP есть группа разработчиков, The League of Extraordinary Packages, которые объединились вместе для создания целостных, хорошо оттестированных PHP пакетов, использующие современные стандарты при написании кода. Они имеют большое количество независимых, высоко качественных пакетов для Routing, DI, Events, Commands, OAuth, манипуляции со временем и еще много всего. И здесь нет никаких ограничений для тебя, для использования великолепных библиотек с любым PHP фреймворком. Более того, ты даже можешь комбинировать их, или создать свой собственный фреймворк!

Другой прекрасный пример это “Aura for PHP” - фреймворк-конструктор, состоящий буквально из разделенных компонентов, воссоздающий полный необходимый функционал фреймворка будущего. Ты можешь использовать их независимо или комбинировать как пожелаешь.

[PHP] … фрагментированное, независимое и изолированное сообщество… это один большой океан разъединенных островов.

Хм… иметь возможность быть много раз использованным, изолированным и слабо связанным - это не значит быть “фрагментированным” и “разъединенным”. И все таки, хочу еще раз заметить, что приложение по-типу “Величественный Монолит” - это не единственно возможный вариант!

Monkey Patching

Нужно ли отмечать, что PHP изначально не имеет такой возможности, как вносить “Обезьяних патчей” по своей концепции? И библиотеки не вступают в противоречия друг с другом, когда кто-то подсовывает на лету, в рабочей программе, похожий метод. Да, это ограничение PHP. Ты не можешь делать столько же прекрасной магии, как можешь это в Ruby. Но я реально лучше буду жить без этой “прекрасной возможности” и буду больше продумывать ООП дизайн, чем думать о заплатках.

Большое преимущество PHP - это то, что вспомогательные библиотеки предоставляются явно. Да, в большинстве фреймворков поставляются собственные библиотеки. Но не существует фреймворков, которые подмешивают что-то внутрь твоего приложения.

Но подожди, 5.minutes.ago это так круто!

Не так круто. Очень хорошая мотивация для этого получена из поста на Reddit - realntl (прочитать весь текст).

Вообще, это плохой подход для встраивания магических цифр в код. Константы предпочтительнее, и поэтому, если вы используете целочисленные минуты из ActiveSupport, вероятнее всего вы выкусите с кодом как этот: (кусок кода)

Обратите внимание на избыточность кода, когда я присваиваю фактическое значение переменной. Я имею ввиду, что преимущество целочисленных минут только кажется красивым решением, когда примитивные значения встроены непосредственно в код. Но на самом деле это является последним местом, желаемым для вставки примитивных значений. Другая же сторона медали целочисленных минут (и, конечно же, дней \ недель), это то, что они вообще используются, когда взаимодействуют с длительностью времени относящийся к другой точке во времени - обычно это “сейчас”. В подобных случаях ты хочешь специфицировать ресурс времени потому, что поведение может быть контролировано должным образом для тестирования. Без возможности же контролировать время, ты будешь нуждаться в библиотеке для корректного контроля времени. И вот сейчас, все над чем ты работаешь, стало значительно более сложным и неявным. Это предсказуемо: неявный код всегда создает проблемы, а затем предлагает еще более неявный код для решения этих же проблем.

Итак, какой же хороший путь решения проблемы 5.minutes.ago в Ruby? Взять отдельную Time библиотеку и сделать это: TimeMath.minutes.decrease(Time.now, 5)

В стиле “Обезьяньего патча” для Rails, будет пожертвовать чем-то, в пользу красоты кода, спрятав проблему “жирного контроллера”. Rails пытаются сделать код контроллера меньшим, через некоторые забавные структуры кода, такие как Array#second_to_last и Array#third_to_last или ArrayInquirer. Извините, но это уже становится смешным.

(Уродливый) Синтаксис

Ruby определенно имеет хорошие возможности для написания более “красивого” кода. PHP никогда не был даже близок к этому, со своими требованиями явного указания $this, точек с запятой и скобок. Но, конечно же, это лишь вопрос времени, чтобы привыкнуть к этому. С хорошей IDE, это не влияет на скорость написания кода или читабельность.

В Ruby есть возможность указывать предикативные методы как “admin?”, “access?”, в PHP вы не можете использовать ? в имени метода, и тогда предикативные методы в PHP становятся выглядеть как-то так: “isAdmin”, “hasAccess”.

PHP имеет опциональную (!) типизацию. И поверьте мне - когда вы используете это, это великолепная особенность. Если вы хотите писать код более строгим (входные / выходные данные) ты можешь делать это через языковые родные вещи. Это добавляет натуральной поддержки для DI контейнеров реализации и хорошую автоподстановку в IDE.

DSL

В PHP нельзя сделать DSL, по крайней мере такой, к которому мы привыкли в Ruby.

DSL хорош в тех случаях, когда это используется в Vagrantfile. Но это не хорошо, когда это слишком много используется без каких-либо значащих причин, DSL первый имхо это ошибка. Ты должен создавать монолитную ООП конструкцию первой и тогда упрощать это путем DSL. Но все что исполняется через DSL, должно быть возможным и без него. Тогда мы достигаем принципа “просто это легко, сложное это возможно”.

Метапрограммирование

В Ruby есть превосходная возможность для изменения структуры “по-горячему”. Разработчик может на лету переопределить входящий класс (методы и т.д.). Боже, я так сильно ненавижу это! Потому что ты никогда не знаешь “где этот чертов метод определен”. Но это опасный инструмент и в хороших руках разработчика может делать великие вещи.

В PHP нет ничего подобного. “Магические методы” - это все, что дает тебе PHP для каких-либо неявных преобразований и присвоений: __get() для ловли и отдачи несуществующего атрибута, или __call() для обращения к несуществующему методу. Существует целый ряд таких методов. И чем меньше ты имеешь таких магических методов, тем легче тебе их отслеживать и работать с этим.

Фреймворки

Наконец-то мы приближаемся к главной теме этой статьи. Язык PHP имеет целый мир конкурентоспособных фреймворков. И этот мир формируют ребята из PHP FIG, основываясь на принятии взаимных соглашений. И вместо анонимного лидера, здесь происходит великое соревнование на протяжении более 7 лет. И более того, люди пишут любые приложения со всем этим.

Полнофункциональные фреймворки

• Laravel 5 - один из самых трендовых фреймворков в последние 2-3 года, с большим количеством DDD архитектуры подходов.
• Symfony 3 - считается одним из самых энтерпрайзных фреймворков, с бессвязными компонентами и сохраняет код приложения изолированным от фреймворка.
• Yii 2 - по-моему мнению, один из самых Rails подобных фреймворков, довольно целостный и связанный, в пользу скорости разработки
• Phalcon - довольно уникальный PHP фреймворк как C-расширение, значительнее RPS.
• Zend 2 - один из самых старинных фреймворков, созданный PHP разработчиками компании Zend, но тем не менее имеет очень слабое влияние на другие PHP фреймворки.

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

Наконец, PHP получило вторую реинкорнацию фреймворков пару лет назад! Эти фреймворки пробуют управлять распределенными компонентами и сущностями. Они уважают пакетную экосистему и скорее всего требует просто тонкую обертку (или вообще без нее) для пакета, чтобы чувствовать себя внутри фреймворка “как дома”.

Также здесь есть параллельная вселенная мини фреймворков, некоторые из них это облегченные версии их “больших братьев” (Lumen < Laravel, Silex < Symfony). Но они предлагают монолитную и отполированную маршрутизацию + DI прослойку, для построения вашей бизнес логики так как вы пожелаете.

• Slim
• Lumen
• Silex

Что у нас есть в мире Ruby? Ответ ясен - Rails. И Sinatra, как мини фреймворк.

Держите пальцы скрещенными за Hanami.

Архитектура

К сожалению, я не знаю в PHP настолько же архитектурно независимый фреймворк, как Trailblazer в Ruby. Каждый фреймворк пытается предложить свой архитектурный подход. Например, Laravel предлагает DI, RequestForms, Events и Command/Handler, Entity/Repository и т.д.

Большинство фреймворков в PHP поощряет разделение компонентов и внедрение зависимостей, но, к несчастью, как и в Rails - ни один учитель не использует хорошо эти подходы. И, в конце концов, эта ответственность переходит к разработчику, как создателю своего приложения.

ORM / DAO / Data Access

Это началось с Active Record как ORM, но быстро переросло в Entity / Repository подход. Также здесь много соперников Yii AR с DAO слоем (как бы там ни было, это имеет multy-db поддержку и cross-db выборки, даже Relation DB + NoSQL), Doctrine, Eloquent, PropelORM и т.д.

В Rails у нас есть Active Record - и весь мир крутится вокруг него. Hanami имеет DataMapper подход. И есть фреймворк, незнающей библиотеки Sequel.

Интересный факт, это то, что создатель DataMapper в Ruby пришел из NoORM и сейчас считает все ORM подходы не стоящими потраченных усилий и времени.

Статические Ассеты

В Rails есть великолепный инструмент Sprockets, который был магически классным в ранние дни - он мог компилировать и комбинировать JS, CSS, SASS, LESS и т.д. Вы просто могли расслабиться и забыть об этой проблемме.

Изначально в PHP фреймворках ничего подобного не было. Так как PHP не запускает собственный сервер и файловых наблюдателей. И поэтому Rails были превосходящими в этом.

Но JS/CSS мир изменился. Так быстро, что Sprockets просто не может достичь такой высоты и также быстро (это медленно в dev окружении, assests:precompile задача берет на постоянно при деплое и это не поддерживается всеми последними JS прекомпиляторами). Вся необходимая обработка JS/CSS сейчас выполняется в Node.JS инструментами на подобии WebPack/Babel. Это уже даже как стандарт в индустрии. И Rails потеряли это преимущество.

Сейчас любой может взять Node.JS + WebPack и использовать все современные ES6 + SASS + JS frameworks + “Горячую загрузку” независимо от языка и фреймворка, что он использует. Я делаю это и с PHP и с Rails. Мне не нужны какие-то специальные умения именно для Rails, когда я могу использовать общие инструменты.

Фоновые задачи и очереди

В PHP отсутствует запускатор фоновых задач. В связи со спецификой PHP процессов которая не предполагает жизнь процессов в течении долгого времени. Здесь есть несколько подходов включающих PHP демоны, но PHP требования в некотором роде помогают здесь - процесс наблюдатель + очередь на фоне (Redis, Beanstalkd и т.д.).

Ruby имеет намного больше родных инструментов таких как DelayedJob, Sidekiq и т.д. И что невероятно, когда ты имеешь отложенную операцию “бесплатно” без большого количества обдумывания - ты можешь делать лучше старт как начинание. Но в конечном итоге масштабируемость Ruby очереди задач заканчивается с Redis и т.д.

Поддержка IDE и автозаполнение

Первоначально я удивлялся почему большинство Ruby разработчиков не использует больших и мощных IDE, но используют Sublime и т.д. Потом я понял что даже такие клевые IDE как RubyMine предоставляют тебе почти ничего с точки зрения автозаполнения для Ruby. Потому что это динамическая природа. И это до сих пор продолжает расстраивать меня.

В PHP несмотря на это что также динамическая природа языка, автозаполнения работает намного лучше. И здесь также широко распространен PhpDoc стандарт к анотированию вашего кода дает вам почти 100% правильную автоподстановку даже для динамических фабрик. Код фреймворка и библиотек со всех сторон покрыт анотациями, это что-то вроде правила этикета в PHP добавлять аннотации в код. И мне очень сильно не хватает этого в Ruby.

Тесты

Ruby знаменит возможностями в тестировании надлежащим образом при помощи переоткрывания классов и создания родных заглушек/фальшивок. Для этого действительно не требуется использовать DI для изменения тяжелого поведения кода в тестах. С RSpec, Minitest и Cucumber вы можете делать любой тип Unit, Integration и BDD тесты.

У PHP так же есть некоторое число инструментов для тестирования - главный это PHPUnit. Что предлагает монолитный фундамент для различных проверок и заглушек. Codeception, фреймв&#10#1086;рк для тестирования - предлагает BDD стиль блочных и интеграционных тестов. Здесь также есть подходы копирующие Cucumber (как Behat), но я считаю это едва ли может быть использовано в PHP. Только одно ограничение это в юнит тестах вы можете делать грязные трюки и действительно надо подумать о завимисимостях инъекция или Mock точек входа в ваших классах.

Да, TDD не мертво, вам просто надо правильно смоделировать ваш код.

Выводы

А здесь нет никаких выводов.

В любом случае я не предлагаю вам менять Ruby на PHP!

Я просто надеюсь, что этот пост убедит кого-то, что Ruby on Rails это не такой большой и важный “слон в большой комнате” разработки web приложений. Длительное время люди в “паралелльной PHP вселенной” продолжают создавать великолепные продукты и проводят время с инструментами не хуже, чем в Ruby мире.

Если ты не можешь смотреть достаточно широко - ты знаешь кто виноват!

Обновление от 2016.06.01

Обращая внимание на ваши комментарии здесь, в блоге, и на Reddit, я хочу собрать главные замечания и дополнения, представленные ниже.

Это не про Ruby on Rails, это про множественность и субъективизм

Я не хочу разводить бесполезную дискуссию про недостатки архитектуры Rails приложений здесь, на этой странице. Это вообще не моя главная цель. Я просто попробую показать насколько тяжело повлиять на всю экосистему Ruby. И на сколько по другому выглядит ситуация в мире PHP, с большим множеством фреймворков и субъективизмом в библиотеках.

Эта заметка скорее об Экосистеме, как таковой, в общем виде, без затрагивания каких-либо конкретных фреймворков, или каких-то единичных аспектов языка (таких как “Обезьяньи патчи”).

5.minutes.ago

Хорошо, давайте просто прекратим этот спор. Мы постоянно говорим про разные вещи. С одной стороны это “красота кода”, с другой - обвинения во “внешнем состоянии”. Это просто разные стороны “5.minutes.ago”. Противники говорят: “это ужасный, не очевидный обезьяний патчинг”, сторонники: “это же прекрасно, посмотрите какой красивый и лаконичный код”. И до тех пор пока мы не начнем обсуждать один и тот же аспект феномена “5.minutes.ago” - это просто пустая трата времени.

Laravel

Любопытно, он жалуется на RoR, и тут же, как хороший пример, ставит Laravel. Laravel является практически RoR в PHP.

С точки зрения возможностей, RoR и Laravel имеют очень мало схожего, но, по-правде говоря, в философских терминах, они делят друг с другом намного больше схожих вещей.

На самом деле это вообще не имеет значения, насколько Laravel и RoR похожи друг на друга, и насколько авторитетен /u/utotwel/. Но что более важно, и что я бы хотел особенно подчеркнуть - Laravel не унижает PHP экосистему, не имеет значение что происходит внутри Laravel экосистемы (и это вполне естественно для PHP, как языка, который поощряет написание многоразовых решений, и просто создающий обертки для интеграции в фреймворк, и не наоборот). Но Rails - издевается и сильно влияет на каждый аспект Ruby экосистемы.

Laravel и DDD, да, я сделал громкое заявление, я просто хочу подчеркнуть это вопреки Rails вдохновляет это имеет много продвинутых архитектурных нововведений из коробки: dependency injection, request forms, command bus и т.д.

Behat / Cucumber

Интересно, что побудило назвать его - “практически бесполезным”. Я люблю Behat.

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

Я реально был удивлен как много людей восхваляют Behat / Cucumber. Вы меня извините пожалуйста, но ведь как раз это и показывает, насколько мои слова задели вас за живое. Я всегда видел Behat не более чем инструмент для тестирования. Я конечно имею чрезмерно своеобразное видение на автоматическое тестирование, но Consider Gherkin предлагает не самый простой подход для этого (не обращая внимание, Ruby это или PHP реализация). Тестирование это очень деликатная вещь и я предпочитаю держать как близкое к нативному коду насколько это возможно (с простейшим дебагом и автокомплитом), также использую PHPUnit + Codeception в PHP или Minitest + Capybara в Ruby.

Архитектура

Я отмечал ранее как пример PHP архитектурного фреймворка: Broadway

Broadway это проект предлагающий инфраструктуру и помощников в тестировании для создания CQRS и событийную архитектуру приложения. Broadway старается не мешаться на вашем пути. Проект состоит из нескольких слабо связанных компонентов, которые могут быть использованы вместе для воплощения полного CQRS\ES опыта.