Веб-фреймворки и с чем их едят

Представьте, что вам дали участок земли и попросили построить на нём дом. И не абы какой, а здание в несколько этажей высотой. Вы прохаживаетесь по участку и размышляете, как справиться с задачей. Дому нужен прочный фундамент, утеплённые стены и то, что на языке строителей называется правильно спроектированными инженерными системами. В целом план действий ясен, и вы приступаете к работе.

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

Конечно, в реальности такая ситуация невозможна. Стройку нельзя переделать «на ходу» под новые нужды. Однако при разработке сайтов (и любого другого программного обеспечения) порой случается, что проект уже начат, но окончательные требования к нему неизвестны. Давайте разберёмся, как в этих условиях можно сэкономить себе время и силы с помощью веб-фреймворков.

 

История вопроса

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

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

Спасение

Чтобы уберечь себя от возможных проблем, можно изначально создавать программу на жёстком каркасе, который позволяет подключать к себе дополнительные модули. По сути, мы будем писать свой код только в тех местах, где это разрешено создателями каркаса (в так называемых «точках расширения»). Так мы не поломаем базовые части системы (каркас) и сможем сконцентрироваться на своих текущих задачах.

В мире программирования описанный каркас называют фреймворком (framework). Фреймворк – не обычная программная библиотека. Если библиотека – это просто набор функций, которые не влияют на архитектуру программы, то фреймворк сам, по сути, является архитектурой. Каркас гарантирует стандартную структуру программ и их поведение по умолчанию.

Веб-фреймворки

Всё просто: веб-фреймворки (web application framework, WAF) – это фреймворки для веба. На их основе можно делать не только сайты, но и любые другие онлайн-приложения.

Большинство веб-фреймворков построено по архитектуре Model–view–controller (MVC). Данные в MVC отделены от бизнес-логики, а та, в свою очередь, – от представления (внешнего вида).

Вот типичный набор компонент веб-фреймворка:

  • шаблонизатор. Отвечает за независимость вёрстки от программного кода.
  • роутер. Распознаёт URL, по которому произошло обращение к серверу.
  • модуль доступа к базе данных.
  • модуль кэширования. Ускоряет загрузку страниц.
  • модуль безопасности. Аутентификация и авторизация пользователей.
  • файлы конфигурации.

Фреймворки также управляют сессиями, ведут логи, упрощают использование Ajax и умеют многое другое.

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

Среди популярных современных веб-фреймворков – Zend Framework, Yii, Symfony2, Laravel, CakePHP (PHP), Django (Python), Ruby on Rails (Ruby).

Существуют так называемые микрофреймворки. Как следует из названия, они отличаются небольшим размером и количеством функций. Микрофреймворки хорошо подходят для простых проектов (сайты-визитки), быстрого прототипирования и создания API. Наиболее известны Silex, Fat-Free, Slim (PHP), Bottle, Flask (Python).

От теории к практике

Итак, фреймворки упрощают разработку. Если бы мы жили в идеальном мире, в этом месте я бы написал что-нибудь такое: «Если вы ещё не используете фреймворки, то скорее начинайте это делать». Но вместе этого я сделаю несколько важных замечаний. Из них станет понятно, почему фреймворки нужно рассматривать лишь как один из инструментов в арсенале разработчика.

Фреймворки – не CMS. Да, с их помощью можно разработать свою собственную систему управления контентом. Но будут ли затраченные усилия стоить того? Предположим, у вас есть законченное ТЗ, в котором полностью описана функциональность проекта и перечислены все требования к нему. Проверьте, можно ли реализовать проект на какой-либо известной вам CMS. Если ответ положительный, то в изобретении велосипеда использовании фреймворка нет необходимости.

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

Среди веб-фреймворков не существует «серебряной пули». У каждого из них есть свои сильные и слабые стороны. Нельзя назвать объективно лучший фреймворк, который бы подошёл для любой ситуации и решал бы все проблемы.

Для чего подойдут веб-фреймворки:

  • для крупных сайтов. Гибкость, расширяемость, масштабируемость решений, простота поддержки – все лучшие черты фреймворков раскрываются именно на больших проектах.
  • для рефакторинга старого сайта. Приняли решение о переносе существующего сайта на новый движок? Присмотритесь к фреймворкам.
  • для уникальных проектов. Фреймворк – конструктор, из деталей которого можно сделать веб-приложение с любой функциональностью.
  • для командной разработки. Думаю, многие видели, что случается, когда один и тот же код последовательно правят несколько человек, каждый из которых верен собственному стилю программирования и стандарту оформления кода. Фреймворк унифицирует структуру файлов и иерархию классов, а также навязывает единый стиль оформления кода.

Для чего фреймворки не очень подходят:

  • для несложных типовых сайтов. Разве что вы хотите поставить их разработку на поток и для этого вам нужен собственный движок.
  • для использования какого-либо отдельного компонента фреймворка. Шаблонизация, роутинг, кэширование сами по себе – замечательные штуки. Но лучше взять эти модули в качестве отдельных программных библиотек, чем задействовать целый фреймворк ради одной-двух его функций.

В сухом остатке

Веб-фреймворки – безусловное благо. Они ускоряют разработку, помогают минимизировать риски, дают команде общий инструмент. Кроме того, их изучение способствует профессиональному росту.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Scroll Up