Blogerator.org

× Версия для печати

Изучая в последнее время вопросы современных подходов к web-программированию, я наткнулся на перевод довольно интересной статьи литовского программиста Юзеса Казиукенаса, посвящённой такому явлению, как PHP-frameworks, их появлению и эволюции.

Учитывая, что вопрос использования в своей работе framework’ов встаёт рано или поздно практически перед каждым программистом (а также беря во внимание то, что многие CMS или уже давно позиционируют себя как имеющие свой framework (CMF Drupal), или же движутся в эту сторону (как та же Joomla), мне захотелось поделиться с вами этой статьёй и обсудить то, как вы сами видите будущее web-программирования в общем и сайтостроения в частности.

Надеюсь, вам это будет интересно.

Итак, представляю вашему вниманию перевод интересной статьи литовского блогера и программиста Юзеса Казиукенаса (скорее бывшего литовского, так как Юзес прожил большую часть своего трудового стажа в США, а сейчас живет в Единбурге, Великобритания), и в которой он рассуждает о PHP-фреймворках с точки зрения перспективы.

Юзес кратко рассказывает о том, с чего начинались PHP-фреймворки и почему они важны сейчас. Далее, он заводит речь о следующем поколении PHP-фреймворков и о том, какие из них ему нравятся, а какие не очень. Например, в статье обсуждаются Zend Framework, Symfony и Lithium. Склонность Юзеса к Symfony очевидна, но это не искажает сути статьи. Стоит отметить, что Юзес один из разработчиков Zend Framework и Doctrine, имеет смысл иметь это в виду, анализируя его предпочтения.

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

Вступление

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

Я хочу обсудить здесь то, что я думаю о текущем положении дел, что в нем неправильно, и как новая банда PHP-фреймворков собирается менять ситуацию. 21 мая 2011 г. я выступал на Голландской PHP-конференции (Dutch PHP conference, DPC) как раз на эту тему и затем у меня состоялась весьма интересная дискуссия с некоторыми её участниками.

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

Рождение фреймворков

6 лет назад состоялся релиз CakePHP, одного из первых PHP-фреймворков, и с тех пор мы повидали немало PHP-фреймворков.

В настоящее время их около... Их миллионы, и каждый из них со своей реализацией MVC (Model-View-Controller), DBAL (Database Abstract Layer) и шаблонизации.

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

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

Многие разработчики утверждают, что они знают ООП, но когда появились фреймворки, они были вынуждены доказывать это на деле (до этого вы могли хакать их как только вам вздумается). И фреймворки заставили PHP разработчиков задуматься о том, что такое ООП на самом деле и как оно работает. Попросите кого-нибудь сейчас использовать mysql_query и вы рискуете получить удар в лицо. Дважды. Потому что вы еще будете вынуждены использовать mysql_real_escape_string . Как это было сделано?

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

Они либо последовали за существующими в других языках фреймворками (такими, как Ruby On Rails), либо придумали свои собственные идеи. Так как опыта никакого не было, большинство PHP-фреймворков до сегодняшнего дня есть наследие конструкций, известных каждому: плохих, но не поддающихся исправлению.

Прагматичный подход PHP-разработчиков здесь сильно помог — аналогично тому, как эволюционировал язык PHP, PHP-фреймворки также изменялись и росли, движимые обратной связью со стороны разработчиков, отзывами и пожеланиями. Через пару лет большинство людей уже были довольны, тем, что у нас было. Но если вы посмотрите внимательно, то в 2007-м у нас был Zend Framework 1.0, который, в сравнении с версией 1.11, обладал очень ограниченным набором возможностей. Таким образом, даже сегодня фреймворки быстро развиваются, чтобы удовлетворять всем текущим потребностям разработчиков.

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

Что не в порядке?

Прежде всего, тогда было популярно использовать «магические» функции PHP (__get , __call и т.д.). На первый взгляд, ничего плохого в этом нет, но на самом деле они очень опасны.

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

Zend Framework в течении долгого времени был моим любимым фреймворком (и до сих пор им является для PHP 5.2), но самая главная проблема с ним в том, что он пытается весьма сложным способом быть... библиотекой компонентов. Другие фреймворки следуют тем же путем — вместо использования существующих библиотек, они написали свои собственные. Это привело к появлению огромного количества библиотек на PHP, подобных автономным библиотекам, но по прежнему требующих загрузки всей структуры фреймворка.

Итак, жирные и плохо cпроектированные фреймворки действительно раздражают. И не меня одного.

Новая эра в 2011

Для улучшения этой ситуации люди решили сделать несколько вещей. Главное — это переписать фреймворки с нуля на основе PHP 5.3.

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

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

2011 год знаменует начало Второй эры и совершенно новые вещи, которые, наконец, состоялись, в основном в форме релизов и анонсов.

Интересно, что в 2011 году PHP — это уже не PHP. Или, уже не только PHP. Стек LAMP скучен, и все меньше и меньше используется с новыми инструментами, такими как Nginx и CouchDB. Сегодня интеграция и взаимодействие являются важными элементами.

То же самое и для языка PHP 5.3 — это совершенно новый зверь, который делает возможной удивительную функциональность. Кроме того, если вы используете PHP 5.3, то нет никакой реальной необходимости обеспечивать поддержку обратной совместимости.

Давайте исправим все это в таком случае, не так ли?

После перемещения в GIT многих фреймворков, стало намного проще внести свой вклад в их разработку. Меня особенно впечатлили результаты Symfony, т.к. им удалось привлечь огромное количество разработчиков (см. схему здесь).

Текущий темп очень быстрый, и по сравнению с темпом разработки несколькими годами ранее, фреймворки улучшаются намного быстрее. Много всего было удалено.

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

Front-end также получил много внимания в таких фреймворках, как Symfony. Ими обеспечивается помощь в управлении статическим контентом (JavaScript и CSS) и установкой для них надлежащих заголовков. Серверная сторона получила огромную пользу, избавившись от магии и очистив код, также PHP 5.3 обеспечил огромный прирост производительности.

Новые возможности

Очевидно, что включены все новые возможности языка. Пространства имен, например.

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

Стандарты PSR-o (Professional Standards Review Organization) созданы раньше, но в настоящее время хорошо интегрированы в фреймворки. И вскоре анонимные функции тоже войдут в них.

Я не совсем уверен, что мне нравится растущий список фич, портированных непосредственно из среды Java. Java работает по-другому (и требует около 1 Гб оперативной памяти), так что даже DiC является сложным в PHP.

Посмотрим, насколько это повлияет на нас, но до сих пор я немного волновался, т.к. знаю, что PHP любит легкие системы, а не сложные объектные графы. Не знаю насколько круты эти паттерны, но уверен — они могут создать больше проблем, чем решить.

И что теперь?

Zend Framework 2.0

Он находится на пути к релизу, но все же потребуется некоторое время.

Т.к. Zend Framework имеет массивную кодовую базу, первое, что они сделали — это преобразовали весь код в код, разделенный по пространствам имен. Как только это было сделано, настало время, чтобы начать рефакторинг функциональности и внедрение новых возможностей. В настоящий момент ведется работа по части MVC. Я надеюсь, что в конце этого года все-таки случится финальный релиз.

Lithium

Вот-вот уже будет, находится в режиме разработки, но, кажется, уже довольно близок к готовности. Это совершенно отличный фреймворк от привычных нам PHP-фреймворков, так что хотелось бы его попробовать. Я наиболее впечатлен их реализацией AOP. Само собой, он поддерживает только PHP 5.3+, а кроме того CouchDB и MongoDb, что весьма приятно.

Symfony 2

На мой взгляд, является вожаком стаи. Финальный релиз вышел 28 июля 2011. Список функциональных возможностей труден для понимания, поэтому смотрите их на сайте Symfony. Назову лишь один термин — Bundles (связки). Bundles — это способ получить расширяемое приложение, с помощью внешних компонентов. Умные плагины. Рекомендую интересную статью по Sf2.

Также рекомендую глянуть очень перспективный FUEL.

Заключение

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

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

~

Англоязычный оригинал, слайды-презентация к статье (вернее, к выступлению на конференции по теме этой статьи), 2011