Зачем и когда нужны фреймворки?

Два вопроса из заголовка этой статьи часто себе задают начинающие разработчики. Эта заметка для них, поэтому начну с определения фреймворка. Что понимается под этим понятием? Фреймворк — это каркас вашего будущего приложения, собственно, это слово и состоит из «frame» — каркас и «work» — работа.

Самыми важными (на мой взгляд) компонентами любого фреймворка являются:

1. Заготовка архитектуры, чаще всего это MVC и её вариации.
2. Набор библиотек для решения типовых задач. Например, маршрутизатор, контроль доступа к приложению (RBAC), миграции, валидаторы данных и так далее.
3. Рекомендуемая структура проекта.

Тут нужно сделать небольшое отступление от темы по поводу MVC. Этот составной шаблон проектирования применяется в веб-среде немного в другом виде, нежели в «стандартном» при разработке настольных приложений. Это интересная и большая тема, которая достойна отдельной статьи и видео.

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

Плюсы

Скорость разработки

Почему на фреймворках возрастает скорость разработки? Дело в том, что почти каждый сайт, да и вообще любой проект на любом языке программирования, можно (условно) разделить на две части. Первая часть — это уникальная бизнес-логика, которая требуется заказчику. Вторая часть — рутинная и повторяющаяся. Она присутствует почти у каждого проекта, например, в веб-разработке к таким вещам относится аутентификация, авторизация, интернационализация и многое другое. Часто бывает так, что доля рутины и просто типичного функционала составляет большую часть проекта. А фреймворки, все топовые, уже содержат в себе все это, поэтому скорость и возрастает.

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

Безопасность

При разработке проектов, особенно коммерческих, нужно учитывать безопасность данных заказчика и клиентов заказчика. Обеспечить надежную защиту может, как правило, не каждый разработчик. Чтобы научиться отражать хотя бы основные виды атак, требуется хороший опыт и понимание схемы их организации. На практике это значит, что вы сами должны уметь проводить SQL-инъекции, csrf-атаки, применять xss-уязвимости, а также использовать плохо написанные загрузчики файлов для подкидывания эксплоитов вместо ожидаемых на сервере аватарок и документов.

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

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

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

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

Стандартизация

Это третий плюс по счету, но не по значению. Скажу больше, фреймворки появились в большей степени для того, чтобы выставить рамки для разработчиков. Если вам приходилось работать со средними и крупными проектами, с количеством строк кода хотя бы более 5 тысяч, то вы уже понимаете зачем нужна стандартизация. Для тех кто не сталкивался с такими проектами приведу пример.

Представьте себе проект поддерживаемый тремя разработчиками-бэкендерами. Каждый из них имеет свои предпочтения. Первый не любит разделять код на логические блоки и пишет все в одном файле, и свой серверный код для запроса данных из БД, и CSS/HTML код полученный от верстальщика и все все все. Второй разработчик любит ООП до изнеможения и создает новый класс под каждый чих. Третьему вообще все равно где и что писать, он пришел в проект на неделю и вставляет код туда, куда только может. Подобные проекты, в большинстве случаев, быстро тонут и ситуацию может исправить только архитектор с опытом построения больших приложений, но услуги подобных людей стоят дорого и их не так много на рынке. А результатом работы этого архитектора будет все тот же каркас для работы — фреймворк. Главная задача фреймворков в том, чтобы при написании кода одним разработчиком, другой разработчик как можно быстрее понимал в каком месте он находится и как его дополнить.

Если используете фреймворк (Symfony, Zend, Yii, Laravel и так далее), то все другие разработчики, знакомые с этим фреймворком, по умолчанию понимают как работает ваш проект. Им не нужно тратить многие часы на понимание архитектуры принимаемого на обслуживание проекта. Например, пришедшему разработчику не нужно искать наименования стандартных классов для решения повседневных задач (доступ к БД, кэширование, RBAC и так далее), так как он уже работал с этим фреймворком и знает как и где их вызывать.

Минусы

Порог вхождения

Это первый и самый неприятный для новичка минус, тут сужу по себе. Когда я знакомился с фреймворками, это было время появления Yii первой версии, было сложно. При изучении фреймворка, не важно какого, у вас будет частенько всплывать вопрос — «Зачем все это нужно? Почему нельзя сделать просто?». Как и где правильнее писать код? Откуда берутся используемые классы? Как стоит именовать свои и есть ли уже готовые классы для нужной в текущий момент задачи? Таких вопросов возникает очень много. Для перехода на фреймворк нужно будет хорошенько потрудиться. Как только вы познакомитесь со своим первым фреймворком, дальше все пойдет как по маслу, изучение последующих будет проходить очень быстро, опять же, сужу в этом случае по себе.

Низкая скорость работы

Скорость работы фреймворка ниже скорости работы нативного кода. С этим минусом я частично согласен и упоминать его не хотел, но для объективности скажу. Так как фреймворки сами по себе содержат гораздо более высокий уровень абстракции, чем единичные скрипты, они работают медленнее. Кода больше и на его выполнение нужно больше ресурсов сервера, особенно это заметно на Symfony. Попробуйте запустить «Hello world» и поймете о чем идет речь. Но это не особо важно, так как в современных проектах практически повсеместно используются кэши, которые полностью нивелируют этот минус. Описывать здесь особо нечего.

Ну так когда же использовать фреймворки?

Основные плюсы и минусы на этом заканчиваются. Вернемся к вопросу обозначенному в начале. Когда следует использовать фреймворки? Фреймворки следует использовать для всех нетиповых проектов, то есть когда требуемый функционал нельзя или очень сложно реализовать с помощью имеющихся готовых решений — CMS’ок. Таких, как WordPress, OpenCart, Bitrix, Joomla и так далее.

Примеры типовых проектов: блоги, интернет магазины, форумы и т.д. Другими словами, если вам нужен обычный блог, то не выдумывайте ничего лишнего, берите WordPress и не теряйте время. Если нужен интернет магазин, то возьмите Joomla или OpenCart. Это будет разумный выбор. Но, если заказчику требуется CRM’ка или тот же интернет-магазин с уникальной логикой работы, да еще с желанием вложить в него много денег (раскрутка повлечет за собой большие нагрузки), то используйте фреймворк, так как с помощью него вы в будущем сможете с меньшими проблемами увеличить количество разработчиков и добавить желаемый заказчиком функционал.

Фреймворки часто применяются для разработки стартапов, API-сервисов и корпоративных систем, которые растут в ширину год от года и без фреймворков их поддержка была бы намного труднее. Мне встречались корпоративные решения на чистом PHP, без фреймворков, и могу сказать, что доработка таких проектов похожа на каторгу. В 99% случаев при разработке большого проекта из него вырастает фреймворк, только этот фреймворк создавало и тестировало несколько человек, причем в сжатые сроки, а популярные фреймворки пишут и тестируют сотни, а то и тысячи людей, что в разы сокращает количество багов и просто нелепых кусков кода в проекте.

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