PHP велосипеды. Зачем?
Давно задавался вопросом, почему многие 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. Мне её вполне хватает”. Ну если хватает, то хорошо. Возможно в этом случае фреймворк и не нужен. А вот если перестанет хватать (новые требования, изменения в ТЗ). Тогда придётся подумать о них родимых.
Под конец поста хочу процитировать юзера с хабра:
Среди тысячи говновелосипедов, возможно прямо сейчас растёт грядущая звезда, идёт конкурентная борьба и естественный отбор.
Истина рождается в споре! Пишите свои велосипеды… там где это действительно надо. И тогда это будет не велосипед, а грамотная оптимизация! Удачи!
Прочитал, улыбнуло, не могу удержаться от камента:
Для меня использование фреймворков больше всего напоминает создание html документа в ворде. Считаю фреймворк применимым только в случае если он четко заточен под решение поставленной задачи или требуется выполнение в неоднозначной среде (например jquery вполне приемлемо зачесывает большинство броузеров под одну гребенку). А как только начинает меняться ТЗ в процессе разработки или усложняться задачи, то быстро начинают кончаться прелести фреймворка. И дело тут вовсе не в лени изучать что-то новое, а в не желании разбираться в чужих дебрях, когда что-то идет не так, а дело оказывается не в собственном коде.
Отдельно хочется сказать, как “здорово” все они справляются с высокой нагрузкой или с большими объемами данных, на фреймворке никогда не добиться хорошей производительности и никогда не произвести оптимизацию из-за универсальности, да и потом часто вмешательство в чужой код может вылезти в неожиданных местах.
А еще огорчает то, что многие ограничиваются лишь умением пользоваться фреймворком как конструктором: собирать все из кубиков, а если нет кубика который нужен, то значит задача не решаема (самому кубик смастерить не погружаясь в глубины).
Я не сторонник писать веб приложения на асме, но и не сторонник постройки кубиков и заплаток к фреймворкам. У разработчика со временем начинают накапливаться свои бливатечки, классы и тп, которые со временем перерастают в свой мини-фреймоврк, который, если оказывается удачным, а аффтар не жаден до копейки, вырастает в тот, за который голосуют и обсуждают в подобных статьях 🙂
Ну это вы перегнули 🙂 Те, кто используют фреймворк и не знают его, и те, кто знает, использует и расширяет – две разные категории программистов. Производительность легко можно достичь расширениями, а расширяя фреймворк – написать свой.
Просто подумалось… Часто заявляют, что фреймворк для ленивых, тупых, начинающих и т.д. и т.п., а профи все напишет сам на голом РНР, но вот вроде бы две самых популярных платформы Java и .NET можно сказать один сплошной фреймворк… И никто не призывает писать на голом С или Java. Так почему в РНР всё по другому? Как-то не логично получается… 🙂