...

пятница, 13 июня 2014 г.

Как я выбирал Zend Framework для проектов веб-студии

Начну с того, что Zend Framework (далее ZF) меня заинтересовал четыре года назад. Около года я присматривался к этому фреймворку, после чего наконец решился переписать самописный движок одной из веб-студий, где я тогда работал старшим программистом. С тех пор меня постоянно преследует вопрос «А почему вы выбрали ZF?». Этот вопрос мне задавали программисты, с которыми я вместе тогда работал в веб-студии; задавали партнеры веб-студии, с которыми мы делали общие проекты; спустя несколько лет мне продолжают задавать этот вопрос потенциальные работодатели на собеседованиях. В этом посте я постараюсь объяснить, зачем выбирался фреймворк взамен самописному движку и почему выбрался конкретный фреймворк.

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


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


В третьих, определить проекты, которые будут разрабатываться на базе фреймворка. Основной критерий: ожидаемая длительность поддержки проекта. Разрабатывается ли проект на пару недель. как промо-сайт, или проект достаточно крупный с поддержкой на несколько лет. Лично мне пришлось столкнуться с доработкой проектов, которые были разработаны еще во времена PHP3, когда использовались глобальные переменные. Уверены ли вы, что выбранный фреймворк будет развиваться в течение ближайших пяти-десяти лет? Какая стратегия развития фреймворка у разработчиков? Как часто разработчик выпускает новые версии фреймворка, которые несовместимы? Все эти вопросы очень важны для веб-студии, у которой может быть несколько сотен разработанных проектов при весьма ограниченном штате сотрудников, т.к. неправильный выбор приведет к значительным трудозатрадам при дальнейшей поддержке проектов.


В четвертых, нужно определить, что вы ждете от фреймворка? Гибкость, стабильность, безопасность? Наличие профессионального сообщества, огромное количество готовых примеров? Хорошая документация, вебинары, семинары и сертификаты? Может что то еще?


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


Нужен ли вообще фреймворк?

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


Какому фреймворку отдается предпочтение?

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


Какие проекты?

На самом деле у средней веб-студии обычно огромное количество проектов, и никогда заранее не знаешь, какой проект будет следующим. Приведу пару проектов для примера, один из которых относительно старенький, а другой только планировался к разработке:


Первый проект:

— поддерживается с 2006 года, ожидается длительная поддержка

— включает несколько языковых версий сайта

— включает несколько сайтов с общим административным интерфейсом

— проект на виртуальном хостинге


Второй проект:

— поддерживается с 2011 года, ожидается длительная поддержка

— включает API для внешних взаимодействий

— включает несколько административных интерфейсов

— важен быстрый старт проекта

— важны безопасность, стабильность, скорость отклика

— проект на выделенном сервере


Что ожидается от фреймворка?

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


Но какой же проект соответствует всем этим ожиданиям?

Т.к. ожидается длительная поддержка проектов, то стоит опираться на ветеранов, которые уже давно существуют, но все еще регулярно выпускают стабильные релизы. Таковых к сожалению не много, например: CakePHP, CodeIgniter, Symfony, Zend Framework.


Далее изучаем changelog's:




Далее изучаем документацию:

Кроме этого, у ZF и Symfony имеются dev — порталы: http://ift.tt/SGa4OA и devzone.zend.com/. а также видео-курсы: www.screenfony.com/ и www.zendcasts.com/ (т.е. проще изучить фреймворки на профессиональном уровне). Также, в России регулярно проводятся конференции ZF.


На данном этапе лидируют ZF и Symfony по уровню документации с примерами и развитому профессиональному сообществу, а CodeIgniter явно проигрывает по уровню безопасности.


Как видим, изучение документации и changelog's помогает предварительно изучить стабильность, безопасность и функциональность фреймворков. Далее последовало определенное время, в течение которого я изучал выбранные фреймворки, сравнивал функционал, проводилась работа по интеграции с текущими проектами и только потом пришло понимание, подтвержденное практикой, что по совокупности составляющих ZF подходит нашим проектам.


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


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Комментариев нет:

Отправить комментарий