<rmcreative>

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

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

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

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

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

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

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

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

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

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

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

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

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