Давно задавался вопросом, почему многие PHP программисты пишут свои велосипеды (CMS,CMF,ORM и т.д.)? Ведь есть куча готовых наработок, готовые PHP классы, PEAR. Почти все стандартные задачи, которые встречаются в веб-разработке, уже реализованы в Zend Framework да и во многих других фреймворках. И я решил провести небольшое исследование…Запостив опрос на Хабре, сейчас я смотрю результаты и всё больше удивляюсь. Вопрос был следующий:

Какой PHP фреймворк вы используете? И почему?

Проголосовало 2020 человек. Воздержалось 649 человек.

Результаты мягко говоря обескураживающие. Почти 40% PHP программистов пишут велосипеды или не используют стандартные решения (в виде каркасов веб разработки). Это печально.

Среди фреймворков лидирует Zend Framework. Оно и понятно, всё-таки он от разработчиков самого языка PHP, поддерживает enterprise-решения, да и русскоговорящее сообщество очень большое. В номинации “Прорыв года” выиграл молодой, но очень амбициозный фреймворк Yii! Сейчас множество вменяют Zend Framework’у низкую производительность, и в своих попытках найти альтернативу очень часто находят её в Yii, который своим основным козырем видит скорость работы. Но мы-то знаем, как надо правильно готовить ZF, поэтому не будем спешить с выводами.

Почему?

В комментариях к опросу есть множество вариантов. Постараемся выделить основные причины:

• “Лень изучать что-то новое”. Самый распространённый вариант. Ну тут как говориться добавить нечего.
• “Я всё сделаю сам. Мне не нужны эти ваши фреймворки!”. Некоторые считают себя гениями, которые объемный код напишут и, главное, отладят в одиночку быстрее, чем сообщество.
• “Уже есть свои наработки и они оформлены в виде фреймворка. Публиковать их не хватает сил/времени”. Таких кстати очень много. Но опять же своё решение никогда не будет стандартизировано по определению, оно будет не с чем не совместимо, и развивает его исключительно разработчик… который потом может уйти с работы и это решение уже будет проблемой работодателя.
• “Фреймворки тормозят, они монструозны”. Тут могу сказать, что грамотное кэширование решает. Также в хороших фреймворках типа зенда есть возможность отнаследоваться и оптимизировать всё, что душе угодно. Во общем списываем этот вариант либо на незнание, либо опять же на лень.
• “Когда надо сделать что-то быстро, фреймворки только увеличат время разработки”.

полагаю, что фреймворки более популярны в сравнительно узком сегменте коммерческого коммандного программирования.
для php в целом, как основного языка веб-разработки– больше доля фрилансеров-одиночек, чаще выбирающих «чистый php» плюс «свои наработки», (которые, как правило, не хочется определять столь громким термином, как «фреймворк»))

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

• “Фреймворк не использует последние технологии типа PHP 5.3, а я хочу”. Ну тогда смотрите в сторону Zend Framework 2 и Symfony 2.
• “Фреймворки не универсальны”. Ну это вообще бред. Фреймворки как раз задумывались как универсальные инструменты. Они гораздо универсальнее CMS. Скажем так, в Symfony заложено 5 компонентов, ZF изначально модульный, так что в нём возможно изменение архитектуры и даже внутреннего устройства.
• “Фреймворки слишком универсальны, слишком много придется допиливать и это займёт много времени”.  А написание с нуля займёт времени меньше? Это верно только для маленьких задач, а вот когда выплывают разнообразыне требования, заказчик меняет условия, меняется дизайн а MVC архитектуры нет. Тогда становится понятно, что лучше было сразу делать на фреймворке.
• “Фреймворк усложняет структуру”. Вовсе нет, фреймворк предоставляет вам каркас, набор инструментов. Да, научиться его использовать стоит некоторого труда и временных затрат, однако потом вы увидите, что работать стало легче! А подстраиваться под стандарты — это в первую очередь сдерживать свою дурную голову и учиться на тех решениях, в которых месяцы человеко-часов работы людей совсем не глупых. Фреймворк предоставляет инструмент и задает типовой каркас приложения. Наличие типового каркаса снижает стоимость вхождения в проект.
• “Сторонние фреймворки не люблю по причине того, что больше нравится писать на «чистом» php.”. Отлично, ну давайте тогда веб-приложения на ассемблере писать. Мне кажется это лень осваивать новый диалект PHP в лице фреймворка.
• “Старые клиенты, старые проекты. Надо поддерживать.”. Если не удастся уговорить клиента заплатить за переход (а скорее всего так и будет), то не остается выбора, приходится поддерживать.
• “Фреймворки хороши на начальном этапе, когда опыт не позволяет писать сложные вещи.”. В последствии они также дают выигрыш в скорости разработки, а это очень важно. С опытом понимаешь, зачем нужны стандарты.
• “Зачем фреймворки, есть CMS. Мне её вполне хватает”. Ну если хватает, то хорошо. Возможно в этом случае фреймворк и не нужен. А вот если перестанет хватать (новые требования, изменения в ТЗ). Тогда придётся подумать о них родимых.

Под конец поста хочу процитировать юзера с хабра:

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

Истина рождается в споре! Пишите свои велосипеды… там где это действительно надо. И тогда это будет не велосипед, а грамотная оптимизация! Удачи!