Это перевод статьи Ruby (on Rails) ecosystem bittersweet or "we like to hate PHP", написанной 30 мая 2016, т.е. совсем недавно. Я полностью согласен с её автором, и сам давно горел желанием написать что-то подобное в последнее время, но у меня не так много опыта с Ruby, поэтому моя писанина не была бы настолько объективна, как писанина человека, который этот опыт имеет, и имеет его в хорошем количестве. А тут на тебе: всё в одном месте уже собрано, и мысли прямо один в один как у меня. Грех не перевести на русский. Также, статья вообще очень хороша как небольшой набор объективного и беспристрастного анализа двух языков современной веб-разработки. В общем, далее — перевод слов автора.
многобукв; нечитал;
В этой статье я рассказываю о некоторых фактах и персональном опыте для того чтобы доказать, что PHP в данный момент живее, конкурентоспособнее, а также имеет менее связанную экосистему, чем Ruby. Я говорю о Производительности, Синтаксисе и Аспектах кодинга, Сообществе и Инструментарии разработчика.
Если у вас есть желание пропустить воду — проскрольте до заголовка "Основная часть начинается здесь..." :) Но мне нужно это сказать...
Что? Очередная анти-RoR проповедь?
Ну да, я начал собирать материал для этого поста больше шести месяцев назад, и я знаю о всех дискуссиях, которые ведутся на тему "за" и "против" RoR в последние недели. Основные обсуждаемые нынче статьи — это Моё время с Rails закончилось и Rails выйграл: Слон в Комнате. Я определённо не настолько опытен в RoR, чтобы сказать что-нибудь новое на тему архитектуры, что ещё не сказал кто-то другой. Я только хочу поспорить за лидерство Rails в веб-разработке.
[PHP]… фрагментированные, независимые и изолированные сообщества… Это один большой океан разрозненных островов.
Сказал как-то AkitaOnRails, и всё это правда с одной стороны, и ложь — с другой. Дорогие рубисты, позвольте мне продемонстрировать вам вашего ближайшего конкурента: PHP. И не существует чего-то особенного в Ruby для типичного Basecamp приложения, чего мы не можем найти в PHP.
Эволюция моего видения...
Я пришёл в мир Ruby только около полутора лет назад, после более пяти лет разработки на PHP. Я испытывал много мучений. Это не лёгкая миграция и адаптация. Жизнь сложилась так, что я решил с нуля создать команду разработчиков Ruby (on Rails) в MobiDev. С того момента я замешан в самообучении и ускорении развития своих Ruby джуниоров и миддлов.
Очень скоро я понял одну вещь: все эти хипстерские и cool-kids образы из мира RoR были немного преувеличены. Сегодня, RoR не предлагает ничего особенно более лучшего, чем любой средний PHP фреймворк, разве что за исключением фоновых задач из коробки.
Что ещё хуже: он стимулирует некоторые подходы к разработке, которые "считаются вредными" © даже в PHP. Тут поощряются нарушение принципа единственной обязанности и CQRS прямо самим фреймворком. И, если честно, большое RoR приложение является тотальной магией из-за вездесущих монки-патчей неявного включения во всё подряд.
Просто подумайте об одном примере нарушения принципа единственной обязанности...
"Разве мы не перестали работать с PHP по этой причине?"
Прости Ник, я цитирую твою книгу, и не согласен с данным утверждением. Я вижу, что огромное количество Ruby разработчиков любят пошпынять PHP. Большинство из них не видели ни одной строки реального PHP кода, но "мой друг сказал мне… что это кошмар". Или они видели WordPress — самый популярный и самый уродливый с точки зрения архитектуры PHP код, который когда-либо был написан.
Я хочу заявить о том, что это некорректное для 2016 года, и PHP сообщество имеет множество таких вещей, которые отсутствуют в сообществе Ruby на данный момент.
Piotr Solnica
В мире Ruby фреймворк следующего поколения никогда не появится... http://disq.us/9qybwk
И, простите, но перед тем как перейти непосредственно к PHP, я должен оставить здесь два риторических для Ruby параграфа...
Это как домашнее насилие
Когда я думаю о Rails и о реакции большинства рубистов на предложение "думать вне RoR", это напоминает мне поток сознания жертвы бытового насилия. И что-то вроде Стокгольмского Синдрома зависимых от RoR.
Вообразите эту печальную, но правдивую историю. "Золушка" живёт в холодном, страшном и адски сложном мире. Она влюбилась в Очаровательного Принца. Он просто потрясающий: понимает её с первых слов, делает её жизнь такой яркой, обещает всегда её любить и делать для неё всё, что она попросит...
Они поженились и переехали в его замок. И её жизнь немного изменилась...
После множества прожитых совместно лет, она уже не может сделать и шага без Его разрешения, Он даже мог побить её, когда она пыталась. Она должна докладывать о каждом своём шаге и подстраивать всё под Его течение жизни. Она уже давно забыла о том, как можно жить без его чрезмерной опеки и помощи со стороны слуг. Все люди, которых она знает и с которыми она общается — такие же жёны домашних тиранов. И всё чаще и чаще она слышала от её "очарования": "Даже не думай оставить меня! Никто не нуждается в тебе, кроме меня! Ты не можешь ничего сделать в одиночку!"...
Замкнутый круг спроса
Ответ: ничего. Нет ничего запрограммированного в Ruby для того чтобы остановить тебя при использовании своих острых ножей для того, чтобы разорвать отношения с разумом. Мы претворяем в жизнь такие хорошие соглашения путём подталкивания и через обучение. Не через запрет острых ножей и не через призывы использовать ложки для нарезания помидоров.
DHH, "Provide sharp knives"
Образование. Rails действительно учат нас?
Разработчики начинают использовать Rails. Обучаются только рельсам. Не могут сделать шага без них. Не могут отличить, что является чистым Ruby, а что является рельсовым монки-патчем. Они не видят чего-то лучше этого, да и не хотят ничего лучше. Не могут сделать даже крошечный SQL запрос без ActiveRecord. Производительность? Кто об этом заботится? Клиенты попадают на Rails-маркетинг и "широкое сообщество разработчиков". Они требуют, чтобы проекты писались на Rails. Разработчики используют Rails потому что это так легко (не просто!), ну и Клиенты же хотят Rails (спрос рождает предложение).
Когда вы подумаете о том, куда пойти после Rails — вы поймёте, что идти, в общем-то, некуда. Клиенты не желают писать не-Rails приложения, потому что они "скорее всего не нашли бы не-Rails разработчиков". То же самое с разработчиками: они боятся оставить Rails, потому что "они не смогут найти не-Rails работу". Порочный круг. И уже нет разницы, "предложение рождает спрос", или же наоборот.
Такой проблемы не существует в мире PHP. Клиенты почти никогда не требуют какой-то конкретный фреймворк. Разработчики, в свою очередь, имеют возможность свободно выбрать тот инструмент, который они знают, и который лучше всего подходит к требованиям. Да, тут есть много Rails-подобных фреймворков, но также здесь имеется и набор фреймворков с отличной философией.
╰( •̀ε•́╰) Основная часть начинается здесь...
Эволюция и Производительность
В 2005-м PHP зарелизил версию 5.0, и ООП-подходы стали возможными для реализации (с момента релиза версии 3.0, там были очень ограниченные возможности ООП). Безусловно, RoR здесь является правопреёмником. И PHP не мог показать нечто конкурентоспособное в течении долгого времени.
Но, начиная с 2012, PHP получил массивный толчок вперёд вместе с версией 5.4, HipHop VM от Фейсбука и расширением экосистемы. Сегодня, с версией 7.0 и HackLang от Фейсбука, PHP имеет увеличенную вдвое производительность и низкое потребление памяти. Это определённо не медленнее Ruby 2.x.
Самое большое преимущество PHP приложений заключается в том, что скорость работы кода не зависит от Dev / Production окружения. Он не требует перезагрузки классов (т.к. каждый новый запрос использует актуальный код). Только расширение отладки даёт некоторый штраф. Но Production окружение не выкинет вам какое-то неожиданное поведение, так как обычно нет никакой разницы где запускается ваш код.
Будущее PHP ясно, потому что он имеет корпорации, стоящие за ним — Zend, Facebook, и так далее. Они постоянно работают над языком для того чтобы сделать его ещё лучше и быстрее.
Что насчёт Ruby? Множество туманных реализаций с туманный перспективами. (прим. переводчика — есть ещё такая вещь как Elixir, который тоже во многом является приёмником Ruby)
Сообщество
Не смотря на то, что корпорации вкладываются в развитие PHP, сам по себе он имеет реальное сообщество — PHP FIG (Framework Interop Group)
Идея группы заключается в общении представителей проектов для обсуждения общих проблем между разными проектами и совместного поиска путей решения. Наша основная аудитория — это мы сами, но мы очень хорошо понимаем, что остальная часть PHP сообщества наблюдает за нами. Если другие желают принять то, что мы делаем, они могут это сделать, но это не является целью. Никто в группе не желает указывать вам, как программисту, как вам следует разрабатывать своё приложение.
И эти парни из множества PHP проектов работают вместе (да, иногда они очень громко ссорились) и предлагают хорошо продуманные Стандарты Рекомендаций PHP. И сообщество реально принимает их через какое-то время.
Спасибо PHP FIG за то, что мы теперь имеем такие важные вещи, как Стандарты Кодинга и Стандарт Автозагрузки по Неймспейсам. Трудно переоценить, насколько важны эти вещи для современного PHP. Это действительно даёт нам возможность совмещать различные проекты и библиотеки в одной безконфликтной кодовой базе.
Я честно не вижу ничего подобного в Ruby, есть лишь Rails-диктатура.
Пакеты
Да, Bundler и Gems были удивительны для Ruby, и ручное копирование-вставка в PHP была ужасной. Начиная с 2012, PHP получил Composer, спасибо стандартам PHP FIG. Его цель в управлении пакетными зависимостями и в автозагрузке кода приложения.
Самая большая разница в том, что зависимости PHP хранятся на уровне проекта (каждый проект скачивает свой набор зависимостей), и по этой причине не может возникнуть каких-то коллизий между проектами.
Код автоматически загружается на основе Неймспейсов. И на практике это работает лучше, чем Constant Autoload в Rails с Ruby модулями. В PHP все пакеты имеют уникальное имя поставщика в Неймспейсе, и это позволяет очень легко отследить, какой код был загружен. Я реально имею массу проблем с этим в Rails, и не имею никаких проблем на стороне PHP.
PHP имеет Лигу Выдающихся Пакетов — группу разработчиков, которые объединились вместе, чтобы построить прочные, хорошо проверенные PHP пакеты с использованием современных стандартов программирования. Они имеют множество высококачественных независимых пакетов для Роутинга, Внедрения Зависимостей, Событий, Команд, Авторизации, Манипуляцией временем и многого другого. И нет ни одного ограничения для того, чтобы вы использовали эти прекрасные библиотеки в любом PHP фреймворке. Вы даже можете совместить их и создать свой собственный фреймворк!
Другой прекрасный пример — Aura for PHP — это полнофункциональный фреймворк, но состоящий из слабо связанных компонентов, которые вы можете использовать самостоятельно, или комбинировать из них то, что вам нужно.
[PHP]… фрагментированные, независимые и изолированные сообщества… Это один большой океан разрозненных островов.
Хм… Быть реюзабельным, изолированным и слабо связанным — это не значит быть "фрагментированным" или "разрозненным", и Магический Монолит — это не единственный архитектурный вариант!
Монки патчинг
Следует ли мне рассказывать о том, что PHP не имеет возможности монки-патчинга в своей основе? И что пакеты не сталкиваются друг с другом, когда какой-то монки-патч уже создал подобный метод в объекте. Да, это является ограничением PHP, вы не сможете делать много всякой магии как в Ruby, но мне правда лучше живётся без этих "острых ножей", и лучше думать о правильном OOП-дизайне, чем о заплатках.
Большое преимущество заключается в том, что утилиты предоставляются в явном виде. Да, есть их некоторое количество, и большинство фреймворков поддерживают свои собственные. Но любой фреймворк подталкивает что-то в ваше приложение.
Но подождите!
5.minutes.ago— это же так прикольно!
На самом деле не очень. Очень хорошая мотивация для этого даётся realntl на Reddit (читать полный текст)
Это в своей основе плохая форма: вставлять магические цифры в коде. Предпочтительнее использовать константы, и из-за того, что вы используете
Integer#minutesот ActiveSupport, вы скорее всего закончите кодом вроде этого:
class Foo
MINUTES = 5
def bar
MINUTES.minutes.ago
end
endОбратите внимание на избыточность, которая содержится в указанном мною моменте в то время когда я назначаю значение переменной. Это означает, что вся польза от
Integer#minutesбудет только в ситуациях, когда элементарное значение вкладывается непосредственно в код — что на самом деле является наименее желательным местом, в которое было бы хорошо поместить это элементарное значение. Другой недостатокInteger#minutes(и, естественно, дней/неделей) это то, что он в основном используются для работы с временными отрезками, связанными с другой точкой времени — как правило, "сейчас". В этих ситуациях у вас возникнет потребность в указании источника времени, чтобы поведение можно было бы корректно контролировать во время тестов. Без возможности управления временем, вам придётся использовать timecop style gem для решения этой проблемы. Отныне всё, над чем вы работаете, стало более сложным и менее явным. Это предсказуемо: неявный код создаёт проблемы, а потом в качестве решения предлагается ещё более неявный код.
Так каков же правильный путь для того чтобы сделать 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 имеет опциональный(!) Контроль типа. И поверьте мне — когда вы привыкнете к этому, вы поймёте, какая это удобная функция. Если у вас есть стремление сделать свой код более строгим, вы всегда можете сделать это через нативные языковые конструкции. Это позволяет добавить натуральную поддержку реализации контейнеров Внедрения Зависимостей, а также получить классное автодополнение в IDE.
DSL
PHP не имеет DSL, по крайней мере такой, какой существует в Ruby.
DSL хорош в тех ситуациях, когда он используется где-нибудь в Vagrantfile. Но не очень хорошо, когда его использованием злоупотребляют без хороших причин, стремление писать всё в DSL ИМХО некорректно. Вы должны сначала создать прочную ООП конструкцию, а уже потом упрощать её с помощью DSL. Всё, что делается через DSL, должно делаться и без него. Таким образом мы согласуемся с принципов "Простое легко, сложное возможно".
Метапрограммирование
Ruby имеет непревзойдённую возможность к динамической композиции во время выполнения. Разработчик имеет возможность переопределить элементы Класса (методы, и так далее). Господи, как я это ненавижу! :D Потому что я никогда не знаю "где найти это ***ое определение метода". Но это "острый нож", и в хороших руках разработчик может делать великие вещи.
В PHP нет такой силы. Единственная магия, которую вы можете делать — это использовать "магические методы" типа __get для получения и возвращения отсутствующего свойства или __call для реакции на отсутствующий метод. Есть некоторый набор подобных методов. И, тем не менее, меньшее количество магических возможностей, которое у вас имеется, упрощает анализ кода.
Фреймворки
Наконец, мы подошли к главному пункту. Мир PHP имеет полноценный конкурентоспособный мир фреймворков. Это именно те парни, которые формируют PHP FIG и принимают взаимные соглашения. И там нет единогласного лидера. В течении более семи лет между ними существует большая конкуренция. И люди пишут любые виды приложений на всех этих инструментах.
Полнофункциональные фреймворки:
- Laravel 5 — один из самых трендовых фреймворков в последние 2-3 года, с большим количеством DDD архитектурных подходов.
- Symfony 3 — считается одним из самых Enterprise-подобных фреймворков, имеет слабо связанные компоненты и хранит код приложения изолированным от фреймворка.
- Yii 2 — имхо, один из самых "рельсовых" фреймворков, довольно твёрдый и связанный в пользу скорости разработки.
- Phalcon — совершенно уникальный PHP фреймворк, работающий как C-расширение, имеющий самый высокий показатель количества запросов в секунду.
- Zend 2 — один из самых старых фреймворков, созданный компанией Zend, разработчиками PHP, но, тем не менее, имеющий очень низкое влияние на рынке PHP кадров.
Большинство данных фреймворков изначально были вдохновлены Rails или каким-то другим PHP кадром (который, в свою очередь, был вдохновлён Rails :)). И первая версия Yii фреймворка была также очень устойчива к изменениям в соглашениях. Но, как вы видите, все они уже были пересмотрены и переписаны по несколько раз. И в множестве случаев это касалось больших изменений в архитектурном .
PHP получил "второе" поколение фреймворков ещё пару лет назад! Они пытаются управлять слабо связанными компонентами и сущностями. Они уважают системы пакетов и большинство из них требуют лишь небольшую обёртку (а иногда и вовсе никакой обёртки) для пакета, чтобы он стал чувствовать себя внутри фреймворка "как дома".
Помимо прочего, существует также параллельная вселенная мини-фреймворков, некоторые из которых являются урезанными версиями "старших братьев" (Lumen < Laravel, Silex < Symfony). Но даже они предоставляют прочные и отработанные механизмы роутинга и внедрения зависимостей для создания такой бизнес-логики, которая вам может потребоваться.
Что мы имеем в мире Ruby? Ответ прост: Rails. И ещё Sinatra, мини-фреймворк.
Молитесь Всевышнему за Hanami.
Архитектура
К сожалению, в PHP я не знаю разобранного архитектурного фреймворка (такого как Trailblazer в Ruby). Каждый фреймворк пытается предложить свой собственный архитектурный подход. К примеру, Laravel предлагает DI, RequestForms, Events и Command/Handler, Entity/Repository, и так далее.
Большинство фреймворков в PHP поощряют разделение компонентов и внедрение зависимостей, но, к несчастью, как и в Rails — никто не учил их хорошим и правильным подходам. Всё это по большей части зависит от самого разработчика.
UPD
Я нашёл пример архитектурного фреймворка в PHP: Broadway
Broadway является проектом для создания инфраструктуры и помощников в тестировании для создания CQRS или событийно-ориентированных приложений. Broadway старается из-за всех сил, чтобы не встать у вас на пути. Проект содержит несколько слабо связанных компонентов, которые могут быть использованы вместе, чтобы обеспечить полный опыт CQRS ES.
ORM / DAO / Data Access
Это начинается с ActiveRecord в виде ORM'ов, но быстро оценивается в подход с Entity/Repository. Также существует множество конкурентов для Yii ActiveRecord со слоем DAO (кстати, в них имеется поддержка нескольких БД, запросов между несколькими БД, даже между реляционными и NoSQL), Doctrine, Eloquent, PropelORM, и так далее.
В Rails мы имеем ActiveRecord — и весь мир вращается вокруг него. Hanami имеет свой DataMapper-подход. И ещё есть библиотека Sequel.
Интересный факт заключается в том, что создатель DataMapper в Ruby стал NoORM-персоной и теперь рассматривает все ORM-подходы не стоящими усилий.
Статический контент
Rails имеет качественный инструмент Sprockets, которая была магически клёвой в ранние дни: они может компилировать и комбинировать JS, CSS, SASS, LESS, и так далее. Можете расслабиться и забыть про него.
PHP фреймворки изначально не имели ничего подобного. В PHP не запускается свой сервер и наблюдатель изменений. Rails имел превосходство.
Но мир JS/CSS изменился. Так быстро, что Sprockets просто не успевает приспособиться (это очень медленный процесс в Dev окружении, assests:precompiletask нужна вечность при деплое, и он не поддерживает все последние JS пре-комилеры). Вся работа по обработке JS/CSS нынче выполняется на стороне утилит Node.js вроде Webpack/Babel. Это практически промышленный стандарт. И Rails теперь потерял своё преимущество.
Сегодня каждый может взять Node.js + WebPack и использовать все современные ES6 + SASS + JS фрейморки + Горячую перезагрузку, не смотря на язык и фреймворк, который он использует. Я делаю это и с PHP, и с Rails. Мне не нужны специфичные для Rails скиллы, когда я могу использовать общие навыки.
Фоновые задачи и очереди
Одна вещь, которая отсутствует в PHP — это фоновые задачи. В силу того, что его процессы не предназначены для долгой жизни. Есть несколько подходов для подключения PHP демонов, но PHP требует некоторую помощь здесь — супервизоры, следящие за процессами + бекенд для очереди задач (Redis, Beanstalkd, и так далее).
У Ruby здесь имеется гораздо больше собственных инструментов типа DelayedJob, Sidekiq, и так далее. И это является удивительным, когда вы откладываете операции "бесплатно", без всякой дополнительной мозговой деятельности — вы можете сделать более лучший старт на начале. Но в конечном счёте масштабируемые очереди Ruby используются вместе с Redis или чем-то подобным.
Поддержка IDE и авто-завершение кода
Изначально мне было интересно, по какой причине большинство Ruby разработчиков не используют большие IDE, и вместо этого сидят в Sublime, и т.д. Впоследствии я понял, что даже такие классные IDE как RubyMine не дают вам практически ничего в плане автодополнения кода для Ruby. Из-за его динамической природы. И это до сих пор меня расстраивает.
В PHP, не смотря на то, что это тоже динамический скриптовый язык, автодополнение работает намного лучше. И он имеет широкий стандарт PHPDoc, который позволяет аннотировать ваш код, чтобы дать почти 100% корректное автодополнение даже для динамических фабрик. Фреймворки и библиотеки полностью аннотированы, это правило этикета в PHP: аннотация исходных кодов. И мне очень не хватает этого в Ruby.
Тесты
Ruby имеет выдающиеся возможности тестирования благодаря своей способности вновь открывать классы и создавать нативные заглушки. Это действительно не требует использования внедрения зависимостей для изменения сложного поведения кода во время тестов. Вместе с RSpec, Minitest и Cucumber вы можете создавать любые типы тестов: Юнит, Интеграционные и BDD.
PHP также имеет набор инструментов для тестирования — основным является PHPUnit. Он предоставляет прочную основу для различных проверок и заглушек. Фреймворк Codeception предоставляет BDD-стиль Юнит и Интеграционных тестов. Также имеются подходы, копирующие Cucumber (такие как Behat), но я думаю, что это едва используется в PHP. Единственным ограничением является лишь то, что в Юнит тестах вы можете использовать грязные методы и действительно нуждаетесь в обдумывании внедрения зависимостей или создании заглушек для точек входа ваших классов.
Да, TDD не мёртв, вам просто нужно продумать архитектуру своего кода.
Заключение
И нет никакого заключения.
В любом случае, я не призываю вас оставить Ruby и начать работать на PHP!
Я просто надеюсь на то, что данный пост сможет убедить кого-то в том, что Ruby on Rails является не таким уж большим Слоном в Большой Комнате Разработки Веб-Приложений. В течении долгого времени люди из "параллельной PHP вселенной" делают великие продукты и хорошо проводят время вместе с инструментами, которые совсем не хуже того, что существует в мире Ruby. Если вы не можете смотреть так широко — вы знаете, кто в этом виноват!
Обновление от 2016.06.01
На основании на комментариев здесь и на Reddit, я хочу собрать основные поправки и жалобы.
Это не про Ruby On Rails, а про плюрализм и агностицизм
Я не собирался обсуждать недостатки архитектуры Rails в данной статье. Это не основная цель. Я стремлюсь показать, как сильно это влияет на всю экосистему Ruby. И как отличается ситуация в мире PHP с плюрализмом фреймворков и агностицизмом библиотек.
Пост посвящён в целом экосистемам, а не каким-то конкретным фреймворкам или отдельным аспектам языка (вроде монки патчинга).
5.minutes.ago
Окей, просто остановим это :) Мы всегда говорим о разных вещах. Одна сторона пытается убедить в "красоте кода", а другая винит его за "внутреннее состояние". И пока мы будем обсуждать вопрос 5.minutes.ago в таком ракурсе — это будет бесполезно.
Laravel
Любопытно, что он жалуется на RoR и при этом приводит в пример Laravel, когда Laravel — это практически RoR в мире PHP
В определениях функций RoR и Laravel разделяют не так много, но ведь в терминах философии они разделяют намного больше?
Это на самом деле не так важно, насколько Laravel и Rails разделяют, и насколько авторитетен Taylor Otwell. Что более важно, и что я старался подчеркнуть — это то, что Laravel не вредит экосистеме PHP, вне зависимости от того, что происходит в экосистеме Laravel (и это нормально для PHP, так как язык поощряет писать реюзабельные решения и просто делать небольшие обёртки для интеграции с фреймворками, а не наоборот). Что касается Rails — то они делают больно и влияют на всю экосистему Ruby.
Laravel и DDD, да, я сделал слишком громкое заявление, я просто хотел подчеркнуть, что не смотря на то, что он был вдохновлён Rails, он имеет множество передовых архитектурных особенностей из коробки: внедрение зависимостей, формы, командная шина, и так далее.
Behat / Cucumber
Я удивлён, что он "почти не используется". Я люблю Behat
Потому что это не утилита для тестов :) Это инструмент коммуникации, который позволяет вам преодолеть разрыв и избежать недоразумений между вашим бизнесом и вашей технической командой.
Я сильно удивлён тем, сколько людей подняли руки в пользу Behat / Cucumber. И простите, кажется, мои слова могли выглядеть резкими. Я всегда рассматривал Behat как инструмент для тестирования. Я имею очень упрямое видение автоматизированного тестирования, и рассматривание подхода Огурца не самый простой путь (без разницы, реализация на PHP или Ruby). Тесты это очень чувствительные вещи, и я стараюсь держать их ближе к нативному коду, насколько это возможно (с простой отладкой и автодополнением), т.е. я использую PHUnit + Codeception в PHP или Minitest+Capybara в Ruby.
Автор: saggid
