Клановое мышление фреймворков

Статистика: Символов — 12 734/10 739 без пробелов (12 703/10 714 без кода):, слов — 1 990
Разметка: Wiki
Похоже, Twitter приводит к повторению одной и той же ситуации снова и снова.

  1. Я говорю что-то, что считаю совершенно бесспорным
  2. Люди меня не понимают и делают странные выводы
  3. Некоторые начинают бороться с этими странными выводами
  4. Когда я пытаюсь объяснить, почему они ошибаются, люди обращаются в @PHPDrama

Вчерашний комментарий:
<[
  Насколько я понимаю, продвигается «Сообщество Laravel», материалы, блоги и т.д. Можем ли мы прекратить это разделение усилий и быть PHP-сообществом?
]>

Я хотел написать "разброс усилий", но был в сонном состоянии после 24-часового собрания в Атлантик-Сити в кузове микроавтобуса вместе с кричащими детьми, неудивительно, что я допустил опечатку. Но все же высказывание не утратило смысла.

Я так думал, пока не получил огромного количества странных ответов от людей (в основном это были известные имена сообщества Laravel), которые защищались и придирались к вещам, которые я сказал, предполагая, что я имел в виду не что-то логичное, а нечто идиотское. Это довольно обидно для меня, поэтому давайте объясним им это.

==Пакеты==
Когда вы собираете PHP-пакеты, у вас есть два варианта:
  1. Сделать его совместимым со своим любимым фреймворком
  2. Сделать его совместимым со всеми существующими фреймворками

Теперь, если вы выберете первый вариант, тогда а) вы просто стараетесь сэкономить время, или б) вы тормоз. Я говорю о ((http://philsturgeon.co.uk/blog/2012/03/packages-the-way-forward-for-php==независимых от фреймворков пакетах)) с начала 2012 года, когда в Laravael 3 были bundles (связки), в CodeIgniter были Sparks (искры), и у всех остальных было что-то своё особенное. У фреймворков не было большого выбора, кроме как создавать собственные решения, потому что единственным другим вариантом был PEAR (Репозиторий приложений и модулей PHP), и большинство этих фреймворков использовали в качестве одного из своих продающих факторов "избегание PEAR".

За это время мы проделали длинный путь по распространению Composer, и такие фреймворки как Laravel делают большую работу для лучшей интеграции Composer, но многие участники сообществ фреймворков не задумываются о том, чтобы делать их код работающим вне окружения конкретного фреймворка. Даже сам Laravel 4 не очень много говорит о том, как использовать его пакеты за пределами Laravel. Я написал о том, как это делать с пакетом Database, еще в ((http://12devsofxmas.co.uk/2012/12/day-4-mixing-and-matching-php-components-with-composer/==декабре 2012 года)), но это было проще сделать благодаря пакету Capsule (позже включенному в ядро), созданному моим сотрудником для упрощения процесса начальной загрузки. **Я говорю об этом не чтобы "похвастаться", как предположил кто-то, а чтобы подчеркнуть, что я хорошо понимаю, что некоторые пакеты //могут// быть использованы отдельно, но большинство пакетов не так просто загрузить как Eloquent, и есть причина, почему Eloquent так прост.** Большинство пакетов Laravel 4 могли бы выиграть от подобной простой загрузки, и в то же время это может быть довольно жестко для некоторых других пакетов, особенно для таких как Pagination, который требует использования переменных среды, знания Symfony HttpRequest, Views и т.д.

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

Если вы мне не верите, взгляните на каждый конкретны пакет Laravel в ((https://packagist.org/search/?q=laravel==packagist)). Некоторые из них являются переходными (bridge) пакетами для обобщенного кода (который прекрасен), но многие из них работают только с Laravel в основном безо всякой причины. Это печально.

В качестве независимого от фреймворка пакета я часто использую ((https://github.com/cartalyst/sentry/==Sentry)), в котором используется подход "разработано для поддержки всего". Это отличное решение, поскольку оно означает безупречную интеграцию со многими фреймворками, но, конечно, его реализация может быть трудной. Еще один упрощенный подход – хранение пакета в обобщенном коде и указание ссылок на переходные (bridge) пакеты в README.

((https://github.com/php-loep/fractal==Fractal)) – это еще один хороший пример, как и любой пакет из ((http://thephpleague.com/==Лиги выдающихся пакетов PHP)). Лига - это дурацкое/забавное название издателя, которое используется мной и группой друзей для того, чтобы мы могли менять обязанности по проектам без необходимости перемещать их между собой или постоянно получать запросы друг от друга. Все наши пакеты полностью независимы от фреймворков, а переходные (bridge) пакеты указаны в README. Легко и просто.

**Обновление:** Люди предполагают, что написание независимого от фреймворков кода - это что-то такое, на что у обычного человека нет времени, если он пытается достичь своих бизнес-целей. У меня есть две мысли на этот счет:
  * Это на самом деле не так уж трудно. Все, что вам нужно сделать, это убедиться, что ваш код (кроме сервис-провайдера) не требует использования какого-либо фреймворка напрямую. БЕЗ ЖЕСТКИХ ЗАВИСИМОСТЕЙ. Это, так или иначе, упрощает тестирование, и это то, что большинство разработчиков Laravel уже делают при использовании шаблона репозитория. Если вы используете шаблон репозитория, вы можете легко прибрать ваши зависимости от фреймворка за интерфейс полностью идентичным образом.
  * Зачем вы вообще выпускаете пакеты, если вы торопитесь достичь бизнес-целей? Вернитесь и сделайте это после "запуска".

==Разработчики==
Мне не нравится, когда разработчики называют себя "Laravel-разработчиками" или "CakePHP-разработчиками" вместо "PHP-разработчиков". Я пытался убедить людей, что "Web-разработчик" - более подходящий термин, но чем больше я работаю над CLI, API и параллельностью, тем меньше мне кажется, что этот термин подходит. "Разработчик ПО" или "Программный инженер" (Software Engineer) подходит как нельзя лучше, но независимо от того, хотите ли вы зайти так далеко - вы не просто Laravel-разработчик!

Поступая так, вы говорите всему миру: "Я знаю только фреймворк Х." Подобно JavaScipt-разработчикам, которые знают только jQuery, и поэтому, вероятно, бесполезны при работе с AngularJS или Backbone.

Выбирая только один фреймворк для представления ваших навыков, вы делаете себя менее привлекательными для тех, кто предположит, что у вас нет навыков перехода с одного фреймворка на другой. Конечно, они ошибаются, но вы только что потеряли предложение о работе. В конце концов, если вы достаточно хороший PHP-разработчик, чтобы легко использовать любой фреймворк, почему же вы описываете себя так конкретно одним фреймворком? Вы – PHP-разработчик, специализирующийся на Laravel, а не Laravel-разработчик.

==Книги==
Сегодня все кому не лень пишут книги (я в том числе), и сейчас в интернете популярна тема Laravel. Я хочу сказать, что если вы пишете книгу, которая применима к любому фреймворку, то вы определенно должны сделать это. Очевидно, в книге о том "как изучить Laravel" не должен быть описан "запуск миграций в ZF2", но почти во всех книгах о чем-то другом не нужны жесткие требования по конкретному фреймворку. Поэтому и у пакетов не должно быть таких требований, и потому что это вредит вашим продажам, вредит PHP-сообществу в целом и оставляет у людей то же клановое мышление, которое преследовало PHP-сообщество в течение десятилетия.

Это касается и блогов. Статья о Laravel и какой-то области технологий, возможно, должна быть просто статьей о PHP и технологии. Это может отразиться и на SEO. Если кто-то напишет об использовании Neo4j конкретно в Laravel, тогда какой-нибудь другой PHP-разработчик может просто не найти её с помощью поисковика и потратит несколько дней, пытаясь разобраться самостоятельно. Количество человеко-часов, потраченных впустую этими разными PHP-кланами, делающими одни и те же вещи снова и снова, абсолютно возмутительно.

==Ресурсы==
Эта же логика применима и к ресурсам сообщества Laravel.

К сожалению Джефри Вэй решил, что в своем твите я говорю о его ((https://laracasts.com/lessons/laravel-community-crash-course==Laracast видео о сообществе)). И снова, это не так. Laracast'ы играют невероятно важную роль в создании учебных курсов высокого качества для людей, которых интересует конкретно Laravel, поэтому вряд ли кто-то захочет продвигать в них AuraPHP.

Для меня в этом видео нет никакой проблемы, но есть подтверждение того, о чем я говорю. Во вступлении описывается проблема, и далее в видео предлагается решение: "Вы знаете правила, вы присоединяетесь к какому-либо новому техническому сообществу, но вы пока не знаете, кто есть кто, или что есть что". В этом-то всё и дело.

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

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

В дополнение к сказанному, такие вещи как ((http://registry.autopergamene.eu/==Реестр пакетов Laravel)) (ссылка на него дана на основной wiki-странице) опасны. Многие разработчики, вступающие в сообщество Laravel, //крайне// неопытны, из-за минимального порога входа. Это //прекрасно//, и это было одним из самых больших преимуществ CodeIgniter все эти годы, но люди, управляющие различными ресурсами по Laravel, принимают это во внимание при принятии решений. Создавая подобные этому репозитории пакетов только для Laravel, вы учите этих разработчиков приходить и искать пакеты только на этом ресурсе вместо того, чтобы просто... использовать packagist.

Почти каждый день я сталкиваюсь с вопросом "Кто-нибудь знает хороший Laravel-пакет для Х?" В качестве моего ответа обычно служит ссылка на %%(t)https://packagist.org/search/?q=X%%.

==Мораль==
Почему это меня касается? Почему вы должны слушать меня? Потому что я почти десять лет занимался этим дерьмом, и это было ужасно. CodeIgniter то, CodeIgniter сё. Я был заточен на CodeIgniter, вся моя внештатная работа тоже была связана с CodeIgniter. Мой блог был полностью о CodeIgniter, я создавал API в CodeIgniter, я говорил только о CodeIgniter, я почти набил "CodeIgniter" на своем надгробии.

Когда CodeIgniter так достал меня, я подключился к созданию FuelPHP, и использование двух фреймворков преподало мне хороший урок о независимых от фреймворков пакетах. Поддержка codeigniter-oauth2 и fuelphp-oauth2 стала достаточным жизненным уроком.

Я поклялся себе больше никогда не застревать в этом мышлении, и с тех пор вкалываю в ((http://www.php-fig.org/==Группе взаимодействия PHP фреймворков)), помогая в создании новых PSR, помогая решать задачи сообщества, улучшая сайт, создавая новые руководства для направления разработки новых PSR и т.д.

Вся эта работа может быть легко подорвана людьми, бездумно придерживающимися своего кланового мышления, игнорирующими остальную часть PHP-сообщества и создающими слишком много ресурсов только по Laravel.

Разработчики, каждый из вас, представьте, что через 5 лет вы возможно не будете работать с тем же фреймворком.

Это не камень в огород Laravel, или Тэйлора, или кого-то другого из какого бы то ни было фреймворка. Я просто говорю вам, что это возможно.

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

Меня радует, что Тэйлор Отвелл вынес урок из истории с сообществом Kohana, которое не только раскололось пополам между v2 и v3, но также изолировалось от остального PHP-сообщества, имея во главе часто неприятных людей, но безусловно элиту.

К счастью с ним самим этого не случилось. Laravel перешел от v3 к v4 с минимальными проблемами, а v4.1 многофункциональна, но при этом является простым обновлением. Руководство также в целом невероятно дружелюбно... кроме тех случаев, когда они говорят со мной как с каким-то дерьмом.

Но меня беспокоят другие проблемы. Я не хочу, чтобы кто-либо из PHP-разработчиков тратил время на эту клановую чушь. Я не хочу, чтобы люди тратили время на переучивание снова и снова. Я не хочу, чтобы разработчики становились религиозными в своем выборе. Я не хочу, чтобы людям приходилось портировать пакеты для работы с другими фреймворками. Это всё происходит, и это все надо прекратить. Мы PHP-сообщество и вместе мы чертовски огромны. 80% интернета наши, и мы должны стараться работать вместе, а не разделять сообщество, загромождая его ресурсами по конкретным фреймворкам - ресурсами, у которых нет причин на существование.

Я просто прошу вас, помнить об этом, когда вы принимаете решение; как разработчики, так и лидеры сообществ.