О порочной привязанности к фреймворкам

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

Когда я пишу в Twitter, то и дело возникает следующая неприятная ситуация:

1. я высказываю точку зрения, которая кажется мне совершенно непротиворечивой;
2. люди неправильно меня понимают, поэтому делают из моих слов абсурдные выводы;
3. некоторые товарищи с праведным гневом обрушиваются на эти абсурдные выводы;
4. когда я пытаюсь объяснить, что меня поняли неверно, люди начинают жаловаться в @PHPDrama.

Недавно я написал такой комментарий:

Почему надо гордо зваться PHP-разработчиком, а не пытаться втиснуть себя в узкие рамки, скажем, Laravel-разработчика 

As much as I understand pushing the "Laravel Community", content, blogs, etc, can we stop this soloing of efforts and be a PHP community?

— Phil Sturgeon (@philsturgeon) January 2, 2014

(Если я правильно понимаю, к чему ведет продавливание контента, блогов и т.д., относящихся к «Сообществу Laravel», то возникает вопрос: не стоит ли покончить с этими сольными проектами и вновь стать «Сообществом PHP»? — прим. пер.)

Я имел в виду «siloing» (дробление усилий), а не «soloing» (солирование), но писал этот твит на обратном пути из Атлантик-Сити, где провел интенсивную суточную рабочую сессию. Я сидел на заднем сиденье минивэна в компании орущих детишек — поэтому и допустил ошибку. Это же можно понять.

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

Пакеты

Создавая PHP-пакет, вы можете действовать одним из двух способов:

1. сделать так, чтобы этот пакет работал в вашем любимом фреймворке;
2. добиться, чтобы он работал в любом из существующих фреймворков.

Если вы выбираете первый вариант, то делаете это по одной из двух причин: 1) вы пытаетесь сэкономить время; 2) вы некомпетентны. Я писал о пакетах, не привязанных к конкретному фреймворку, еще в 2012 году, когда в Lavarel 3 были «наборы» (bundles), в Codeigniter — «спарки» (Sparks), а во всех других фреймворках были еще какие-то собственные сущности. Фреймворки практически не оставляли нам выбора, кроме как создавать отдельные решения для каждого фреймворка. В противном случае было практически невозможно обойтись без библиотеки PEAR, а ведь основной коммерческий аргумент в пользу целесообразности создания многих фреймворков заключался именно в том, что «фреймворк будет функционировать без опоры на PEAR». 

В те годы мы многого добились благодаря распространению менеджера зависимостей Composer, а некоторые фреймворки, в частности Laravel, значительно поспособствовали его популяризации. Тем не менее, многие программисты, привыкшие работать в рамках одного фреймворка, не умеют писать код, который бы одинаково хорошо выполнялся в любых фреймворках. Даже в Laravel 4 замалчиваются вопросы о том, как задействовать Laravel-специфичный код вне этого фреймворка. Еще в декабре 2012 года я написал о том, как устранить такую проблему для пакета Database, но моя работа упростилась благодаря пакету Capsule (позже вошедшему в состав ядра). Пакет Capsule был написан одним из моих сотрудников для упрощения процесса начальной загрузки. Я рассказываю об этом не из хвастовства, а просто чтобы подчеркнуть, что некоторые пакеты действительно могут использоваться автономно. Однако у большинства пакетов начальная загрузка протекает значительно сложнее, чем у Eloquent, и именно поэтому Eloquent так удобен в использовании. В большинстве пакетов L4 такая легкая начальная загрузка была бы очень кстати, поскольку именно этап предзагрузки во многих пакетах построен слишком громоздко. Достаточно привести пример пакета Pagination, который требует переменной окружения, знаний Symfony HttpRequest, Views и т.д.

Итак, даже сам Laravel не пропагандирует использования своих пакетов вне Laravel. Это не делается даже в простейших README-примерах. Поэтому многие разработчики в сообществе разделяют порочные убеждения следующего характера: «Я решаю все задачи во фреймворке Laravel, мне нет дела до того, работает ли этот пакет в CakePHP». И за минувший год мы не продвинулись практически ни на йоту. У нас есть фреймоврки, плохо взаимодействующие друг с другом, а разработчики продолжают писать код, образцы которого очень плохо стыкуются.

Если вы мне не верите, можете просмотреть Laravel-специфичные пакеты на packagist. Среди них есть связующие пакеты для создания универсального кода (это просто отлично), но многие другие из пакетов, расположенных по этой ссылке, пригодны лишь для использования в Laravel, просто по факту. И это меня огорчает.

Хорошим примером пакета, не зависящего от конкретных фреймворков, мне кажется Sentry. Разработчики постарались включить в него поддержку всех необходимых возможностей. Это отличное решение, во многих контекстах обеспечивающее бесшовную интеграцию, но написать такой пакет определенно непросто. Более простой подход — писать пакет как универсальный, а в файле README ссылаться на связующие пакеты.

Еще один хороший пример — Fractal. Впрочем, хороши все пакеты с ресурса «PHP-лига экстраординарных пакетов». League — это полушутливое пространство имен, которое используем мы с друзьями. В этом пространстве мы можем перераспределять ответственность за разработку пакетов в рамках команды, не пересылая их друг другу и не отвлекая товарищей от работы. Все эти пакеты работают в любых фреймворках, а в каждом файле README вы найдете список нужных связующих пакетов. Все легко и просто. 

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

• Писать универсальный код не так сложно. Вам всего лишь требуется гарантировать, что весь ваш код (кроме сервис-провайдера) работает без привлечения функций, специфичных для отдельных фреймворков. НИКАКИХ ЖЕСТКИХ ЗАВИСИМОСТЕЙ. Такой подход упрощает тестирование; кстати, именно так действуют многие сторонники Laravel при применении паттерна «Репозиторий». Если вы используете этот паттерн, то с легкостью можете скрывать все зависимости за интерфейсом практически идентичным образом.
• Если у вас сроки горят, зачем вы вообще пишете пакеты? Отложите на потом, займетесь этим после релиза.

Разработчики

Меня на редкость раздражают такие люди, которые гордо заявляют: «Я Laravel-разработчик» или «Я CakePHP-разработчик», а не говорят «Я пишу на PHP». Какое-то время я уговаривал таких «специалистов», чтобы они именовали себя «веб-программистами», но чем больше мне приходится иметь дело с интерфейсом командной строки, API и заниматься другой сопутствующей работой, тем меньше мне нравится формулировка «веб-программист». Можете называть себя просто «программистами», но никак не «Lavarel-разработчиками».

Ведь вы фактически заявляете во всеуслышание: «Я разбираюсь только во фреймворке X». Есть такие JavaScript-разработчики, которые разбираются только в библиотеке jQuery, поэтому практически профнепригодны, если требуется работать с AngularJS или Backbone.

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

Книги

Сейчас все кому не лень пишут книги (даже я), а фреймворк Laravel пользуется популярностью в этих ваших интернетах. Думаю, что если вы видите в себе силы написать книгу, которая была бы информативна для работы в любом фреймворке, то этим определенно стоит заняться. Конечно, в книге «Краткий курс Laravel» не должно быть главы «Выполнение миграций в ZF2», но, как правило, книга не должна иметь жесткой привязки к конкретному фреймворку. Это же касается и пакетов. Чрезмерное увлечение излюбленным фреймворком вредит и вашим продажам, и всему PHP-сообществу, страдающему от фреймворковых усобиц на протяжении уже около десяти лет.

Подобные тенденции прослеживаются и в блогах. Задумывая пост о Laravel и о применении какой-либо технологии, лучше напишите о PHP и о данной технологии. Это целесообразно даже на уровне SEO. Если кто-то решит написать о Neo4j, но ограничится лишь примерами для Laravel, какой-то другой PHP-разработчик может пропустить этот материал, так как не упомянет Laravel в поисковом запросе — и потратит лишние несколько дней, чтобы самостоятельно изобрести уже готовое решение. Вдумайтесь, сколько человеко-часов на это тратится, и согласитесь, что такая фреймворковая раздробленность абсолютно противоестественна.

Ресурсы

То же касается различных ресурсов Laravel-сообщества.

К сожалению, Джеффри Уэй решил, что в моем твите, из-за которого разгорелся весь сыр-бор, я намекал на его видео о сообществе Laracast. Это не так. Laracasts делает огромную работу по подготовке учебных ресурсов для тех, кто хочет изучить именно фреймворк Laravel.

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

Вот почему люди так упорно предпочитают один «истинно верный» фреймворк всем остальным. У них в родном сообществе написана масса кода, все их знания там сосредоточены, там все друзья, все RSS-ленты пестрят новостями сообщества, поэтому одна мысль о том, чтобы покинуть эту среду смерти подобна.

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

Наконец, такие вещи, как реестр пакетов Laravel, просто опасны. Многие разработчики, приходящие в сообщество Laravel, крайне неопытны, и в PHP это нормально, так как входной барьер знаний для программирования на этом языке традиционно очень низок. Это отлично, такая легкость на протяжении многих лет была основным коммерческим аргументом в пользу поддержки CodeIgniter. Но те люди, которые отвечают за различные ресурсы по Laravel, также должны учитывать эту характерную легкость PHP, принимая те или иные решения. Создавая целые репозитории пакетов, ориентированных на работу лишь с Laravel, вы приучаете разработчиков просто брать все пакеты на таком сайте, а не… использовать packagist.

Мораль

Почему мне до всего этого есть дело? Почему вам стоит ко мне прислушаться? Потому что я оставался таким узколобым «специалистом» на протяжении почти десяти лет, и это было ужасно. CodeIgniter тут, CodeIgniter там. Я был записным кодеигнитчиком, все мои фрилансерские заказы были связаны с CodeIgniter. Писал блог только о CodeIgniter, разрабатывал API в CodeIgniter, читал лекции о CodeIgniter и уже не сомневался, что слово «CodeIgniter» будет высечено на моем надмогильном камне.

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

Я дал зарок никогда больше не увлекаться каким-то одним фреймворком и с тех пор не покладая рук работаю в Группе по обеспечению взаимодействия PHP-фреймворков. Участвую в подготовке новых стандартов написания кода (PSR), поддерживаю сайт группы, помогаю создавать новые инструкции для ускорения разработки новых PSR и т.д.

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

При этом я не обвиняю только Laravel, только Taylor или какой-либо другой фреймворк. Просто считаю, что такого быть не должно.

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

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

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

Фил Старджен

Источник
 

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.