<rmcreative>

RSS

Фреймворки

6 ноября 2009

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

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

  2. Фреймворк тестируется огромным количеством пользователей. Такого количества тестеров для своего закрытого кода вам не найти. В случае использования фреймворка найденные вами ошибки в ядре могут исправляться достаточно не оперативно. Хотя, конечно, есть и проекты с очень оперативной реакцией на сообщения об ошибках, в своём коде вы можете делать всё, что захотите и при этом никого ждать не надо.

  3. В коде самого фреймворка разбираться сложно. Во всяком случае сложнее, чем в своём (если конечно вы не читаете свой код с перерывом в пару лет).

  4. Фреймворк не «заточен» под ваше приложение. Чаще всего его приходится расширять (см. также пункт 12).

  5. Если предполагается работа в команде, код должен быть документирован. Все знают, как разработчики «любят» писать документацию к своему коду. Хорошие фреймворки, как правило, уже хорошо документированы, так что объём писанины сильно уменьшается, освобождая время для более полезных занятий. Вообще документация — 40% фреймворка. Если нормальной документации нет, разобраться с ним только по коду и отдельным статьям как правило очень трудно.

  6. При использовании фреймворка есть с кем посоветоваться вне команды. Сообщества, как правило, довольно дружелюбны.

  7. Без фреймворка вообще трудно работать в команде: приходится следить за стилем кода, за тем, чтобы использовался уже готовый функционал, а не писались велосипеды. Команда, ознакомившись, с архитектурой фреймворка делает при разработке гораздо меньше ошибок. Если у вас кривое ТЗ или не очень опытные разработчики в команде, фрейморк позволит сделать посадку менее жёсткой.

  8. PHP вместе с фреймворком редко бывает узким местом: «тормоза» несущественны на фоне неграмотной архитектуры велосипедов, игнорирования кеша, не оптимального SQL и других факторов, в гораздо большей степени влияющих на производительность.

  9. Если вы хотите написать чистый хороший код, вы рано или поздно напишете, пусть и уникальный, но фреймворк.

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

  11. Опять про производительность? Разработчики дороже железа. Хорошие разработчики много дороже железа.

  12. Изменение кода ядра фреймворка — это самоубийство. Если фреймворк без изменений в ядре нельзя подстроить под себя — это плохой фреймворк.

Комментарии RSS

  1. №1965
    Mike TUMS
    Mike TUMS 06.11.2009, 4:17:26

    Сей пост выглядит как приглашение разработчиков к созданию нового фрэймворка.

    Я прав, или я прав? :)

    В любом случае - я "за".

  2. №1966
    AlexKey
    AlexKey 06.11.2009, 4:52:57

    Кратко то же самое можно было написать как:"Есть плохие фреймворки, есть хорошие. Хорошо использовать хорошие".

    Извините, не сдержался.

    Вообще читаю вас регулярно, но этот пост просто что то неописуемое.

  3. №1967
    sesharim
    sesharim 06.11.2009, 5:37:41

    Какой фреймворк на ваш взгляд "относительно" не плохой, и достаточно развитый?

  4. №1968
    Антон
    Антон 06.11.2009, 9:10:06

    Согласен с автором.

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

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

  5. №1969
    Dan
    Dan 06.11.2009, 9:49:52

    Kohana - kohanaphp.com

    документироан

    код достаточно прост

    поддерживается сообществом ( в том числе и русскоязычным )

    менять код самого вреймворка менять не надо, ибо ООП

    шустрый =)

  6. №1971
    Nick
    Nick 06.11.2009, 9:55:07

    неужели никто не видит, что фреймворков, которые подойдут всем не существует?

    ты или используешь его или нет.

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

    и так будет бесконечно

  7. №1972
    adw0rd
    adw0rd 06.11.2009, 10:02:30

    Я с PHP постепенно перехожу на Python/Django, вот где нормальный фреймворк и удобный язык.

  8. №1973
    Serge Bezborodov
    Serge Bezborodov 06.11.2009, 10:27:35

    Я в свое время стал перед выбором фреймворка, почитал всякие обзоры, описание, сравнения и остановился на Yii Framework, и в принципе им доволен.

  9. №1974
    DbHelp
    DbHelp 06.11.2009, 11:46:18

    В конце не хватает рекламы Yii :)

  10. №1975
    Sam
    Sam 06.11.2009, 13:22:37

    Mike TUMS

    Как раз эта заметка против создания своего фреймворка. Ну или по крайней мере против своих закрытых фреймворков.

    sesharim

    Django, Yii, Kohana (если не считать проблем с документацией), Zend при грамотном допиливании.

    Dan

    Документация Kohana оставляет желать лучшего.

    Nick

    Я как раз это и хотел сказать. Возможно, не вышло…

    adw0rd

    На PHP тоже есть вполне нормальные фреймворки. Язык, питон, конечно занятный.

    Serge Bezborodov, DbHelp

    Ну почему сразу Yii? Если мы его выбрали, это не значит, что он подходит всем.

  11. №1976
    larin
    larin 06.11.2009, 14:43:26

    Я тоже долго искал FW на PHP. После 3-х лет поисков, пришло осознание, что на PHP просто не может быть удобного FW (ограничения языка )))

    В общем мой выбор Python + Django.

  12. №1977
    Serge Bezborodov
    Serge Bezborodov 06.11.2009, 21:51:30

    2 Sam

    Другие фреймовки толком не использовал(только редактирование чужого кода), yii выбрал прочитав разные обзоры

    Очень интересно попробовать питон с джангой или ruby on rails, все пишут об этой связке словно как заклинание

  13. №1983
    Денис Радченко
    Денис Радченко 07.11.2009, 19:43:55

    Очень качественная статья! Полностью согласен.

  14. №1987
    Иван Броткин
    Иван Броткин 09.11.2009, 8:50:48

    Есть ощущение незаконченности - будет вторая часть размышлений?

    ЗЫ. А мне все равно Kohana нравится. Документации все больше, исходники читаются великолепно. * каждый кулик свое болото хвалит... *

  15. №1985
    Sam
    Sam 09.11.2009, 12:46:52

    Вторая часть пока не намечается.

  16. №1988
    Gore
    Gore 10.11.2009, 13:12:30

    на PHP просто не может быть удобного FW (ограничения языка )))

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

  17. №1991
    the_buddha
    the_buddha 12.11.2009, 0:31:08

    Есть такая магическая связка ruby - ruby on rails && python - django, так вот для php - symfony framework - самое приближенные к тому же!

  18. №2011
    Аноним
    Аноним 20.11.2009, 23:54:11

    Разработчики дороже железа. Хорошие разработчики много дороже железа.

    Ты мыслишь смешными категориями "много - это 1000 хитов в день". И клепаешь очередной говнопроект исходя из своего представления о том, что процессорное время и память нынче дешевые. Но дешевизна эта - она ровно до момента когда количество серверов меньше одного.

    А у некоторых хитов - 300 запросов в секунду. И экономия хотя бы 20% процессорного времени - это возможность сэкономить 20% парка серверов, средняя стоимость каждого - несколько тысяч долларов.

  19. №2012
    Alek
    Alek 21.11.2009, 0:55:01

    ** Аноним **

    Про то и речь, что нужен хороший разработчик, который сможет сэкономить эти "20% процессорного времени".

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

    А статья мне понравилась, очень жизненно.

    А с тем, что "писать своё - утопия" я не согласен. Если б все так думали, откуда бы тогда фреймворки появлялись, да и вообще все новое...

  20. №2013
    Nayjest
    Nayjest 23.11.2009, 1:37:47

    Здравствуйте! Скажите пожалуйста, вы смотрели Recess framework?

    Недавно открыл для себя эту штуку. Сейчас вот готовлю статью о нем в свой блог и на Хабр. На первый взгляд очень приятный фреймворк, дающий высокую скорость разработки, правда сообщество не очень резвое. Интересно мнение других людей. Спасибо.

  21. №2014
    Sam
    Sam 23.11.2009, 12:42:57

    Да, я к нему присматривался, но довольно давно. Идеи там неплохие, но реализация в то время сильно хромала, поэтому сообщество на recessframework.ru я разворачивать не стал.

  1. Почта опубликована не будет.

  2. Можно использовать синтаксис Markdown или HTML.

  3. Введите ответ в поле. Щёлкните, чтобы получить другую задачу.