В статье Маттиас рассказывает о том, какие вопросы должен задать себе разработчик, прежде чем выбрать фреймворк или отказаться от фреймворков вообще. Перевод статьи читайте под катом. В комментариях делитесь своим опытом выбора и использования фреймворков.
Так как я много пишу о разработке распределённых приложений, неудивительно, что один из моих читателей задал вопрос: «Зачем использовать фреймворк?». Короткий ответ: потому что он вам нужен. И вот почему:
- Фреймворк делает за вас слишком многое. Вам потребуется уйма времени и денег, чтобы заменить всё это на самостоятельно написанный вами код.
- Разработчики, поддерживающие фреймворк, исправили множество проблем ещё до того, как вы с ними столкнулись. Они постоянно заботятся о безопасности кода и исправляют проблемы по мере их появления. Вам остаётся только загрузить последнюю версию фреймворка.
- Отказавшись от фреймворка, вы не будете зависеть от Symfony, Laravel, Yii и так далее. При этом вы будете зависеть от своего фреймворка, а это ещё большая проблема, так как поддерживать его вам и очень вероятно что делать это вы не будете (по моему опыту, в проектах с самописным фреймворком, поддержкой самого фреймворка почти никто не занимается).
В общем, фреймворк нужен всем. Но вам всё равно стоит писать независимый от фреймворка код там, где это возможно. Ведь если весь код проекта связан с фреймворком, то:
- Сложно угнаться за изменениями в фреймворке. При обновлении API, пользовательских соглашений или лучших практик фреймворка обновление кода проекта занимает слишком много времени;
- Трудно протестировать любую бизнес-логику без прохождения фронт-контроллера, анализа HTML-ответа или просмотра базы данных;
- Тестировать что-либо будет сложно, потому что изолированное тестирование в таких случаях невозможно. Обязательно нужно будет настроить схему базы данных, заполнить ее данными или поднять какой-либо сервисный контейнер.
Формирование крепкого ядра изолированного кода, не привязанного к технологии баз данных или конкретному фреймворку, даёт больше свободы и предотвращает все вышеперечисленные проблемы. Если вы хотите написать независимый от фреймворка код, не нужно изобретать велосипед. Можно положиться на каталог шаблонов проектирования, например:
- Сервисы приложения и командные объекты.
- Сущности и интерфейсы репозиториев.
- События домена и их подписчики.
Ни один из перечисленных классов не будет использовать такие специфичные для фреймворка вещи, как:
- Запрос, ответ, сессия, хранилище токенов или менеджер безопасности,
- Локаторы сервисов, хэлперы для конфигурации, разрешители зависимостей,
- Подключения к базе данных, построители запросов, мапперы данных (или что там используется в вашем фреймворке).
Для себя я установил несколько правил для проверки изолированности бизнес-логики в проекте:
- Могу ли я перенести это приложение из веба в консоль, не затрагивая ни один из основных классов?
- Могу ли я создать экземпляры всех классов в ядре моего приложения без подготовки какого-либо специального контекста или настройки внешних сервисов?
- Могу ли я перенести это приложение из базы данных SQL в документную базу данных, не затрагивая ни один из основных классов?
Пункты 1 и 2 должны быть выполнены на все 100%. Что касается пункта 3, здесь могут быть варианты из-за извечной проблемы сопоставления сущностей с форматом их хранения. Например, у вас может быть некоторая логика сопоставления в вашей сущности (т.е. инструкции для вашего ORM о том, как сохранять сущности), но не должно быть никаких сервисных зависимостей, специфичных для выбранного вами хранилища. Например вы не можете внедрить EntityManagerInterface или использовать QueryBuilder где-либо в коде. Кроме того, вызовы методов никогда не должны приводить к реальным запросам к базе данных, даже если это Sqlite.
Если вы выполните все эти условия, ваш фреймворк будет выглядеть как обёртка вокруг изолированного ядра:
Этот слой содержит всю техническую информацию. Здесь вы найдете такие аббревиатуры, как SQL, ORM, AMQP, HTTP и другие. И именно здесь не стоит писать всё с нуля. Мы используем мощь фреймворков и библиотек, чтобы не отвлекаться на решение низкоуровневых проблем, а сосредоточиться на бизнес-логике и взаимодействии с пользователем.
Фреймворк должен помочь вам:
- Обеспечить плавный переход выполнения от входящего HTTP-запроса к вызову одного из контроллеров.
- Загрузить, распарсить и проверить конфигурацию приложения.
- Инстанциировать любой сервис, необходимый для выполнения работы.
- Преобразовать ваши данные в сообщения в очереди, которые далее могут обрабатываться внешними воркерами.
- Проанализировать аргументы командной строки и передать их как готовые к работе примитивные типы.
- Превратить данные вашего приложения в записи базы данных и обратно в данные, которые вы можете использовать в своем приложении.
- Отправить HTTP-запросы к внешним сервисам и обработать ошибки соединения и статус ошибок.
- И так далее...
Я считаю, что достаточно хороший фреймворк должен обладать вот такими качествами:
- Хорошо справляется с задачами, обозначенными выше, чтобы мне не нужно было заменять или расширять что-либо самописными реализациями.
- Помогает разработчику: не нужно читать код, чтобы узнать, почему что-либо не работает.
- Экономит время на размышления обо всём этом, предоставляя правильные абстракции.
- Сопровождается хорошей, полной и актуальной документацией, так что каждый может узнать, как с ним работать
- Имеет четкие инструкции по обновлению, которые упрощают переход между версиями (или же это делается автоматически).
В идеале фреймворк также:
- Проводит четкое различие между сервисами и объектами других типов.
- Предоставляет неизменяемые объекты и сервисы без состояния, которые можно вызывать любое количество раз.
- Не предоставляет глобально доступные функции, позволяющие получать сервисы или конфигурацию.
- Запрещает изменять своё поведение через расширение классов. Всё-таки наследование — это опасная форма связанности.
Обратите внимание, всё это необязательные условия! Если ограничиться технологическим слоем вокруг вашего изолированного ядра, то фреймворк, скорее всего, будет использовать разные практики, которые мне кажутся вредными. Но пока эти практики не влияют на дизайн ядра, всё в порядке. Тем не менее, поддержка такой архитектуры требует определённой дисциплины. Когда дело доходит до изолированного ядра, не стоит срезать углы!
28 июня мы соберёмся на PHP Russia 2021. Обсудим, в том числе, фреймворки и библиотеки, расскажем об опыте реализации крупных проектов на PHP. У вас будет возможность пообщаться с core-разработчиками языка. Билеты уже в продаже. Присоединяйтесь!
Комментарии (32)
Dekmabot
23.03.2021 08:23Convention over configuration, так как фреймворк — это не только набор инструментов, но и заранее известные договорённости.
По моему опыту, использование фреймворков уменьшает время onboard`инга нового сотрудника с 2-3 месяцев до 1-2 недель.
avraam_linkoln
23.03.2021 08:23Кстати тоже очень важный момент. Сейчас работаю уже пол года на проекте полностью самописном, там столько скрытой магии происходит, что часто приводит к тому что для того чтоб понять что на самом деле происходит нужно пол дня, так как все это нигде не описано.
Scf
23.03.2021 08:23Верно. Для стандартных приложений, которые работают стандартным образом. Если говорить про качественные решения, они редко являются стандартными, поэтому если решение на фреймворке, то он значительно переконфигурирован и расширен.
Плюс, размер фреймворка, как правило, не позволяет разработчику знать обо всех используемых договоренностях и компромиссах. Плюс, если тебе нужно изменить стандартное поведение, нельзя взять и написать код — нужно искать нужную настройку.
hello_my_name_is_dany
23.03.2021 08:23Мне кажется, вы просто описали гексагональную архитектуру из DDD, а ответ на главный вопрос был только в начале статьи и довольно краткий. Хотелось бы, чтобы побольше раскрыли тему, нужен ли фреймворк, писать свой или взять готовый, а если готовый, то какой и тд.
SamDark Автор
23.03.2021 08:23Даже с фреймворком clean code никто не отменял. Накидывайте вопросов, отвечу на все.
нужен ли фреймворк
Нужен если у вас нет тучи времени и желания собирать свой, писать к нему документацию и поддерживать его. Если есть — тут уже вопрос. Нужно считать.
а если готовый, то какой и тд.
Тут на вкус и цвет и под задачу. Лучше на конкретном примере.
ElisDN
23.03.2021 08:23Как раз осенью сравнивали варианты монолитных и компонентных фреймворков и микрофреймворков в докладе https://youtu.be/MuVMe7oMoyM
russeljo
23.03.2021 08:231. Заказчик может сказать, что им нужен надежный фреймворк, т.е. не битрикс, а symfony или ZendFramework, остальное их не особо волнует. Или что-то модное- современное.
2. На основе ZendFramework сделали своё для корп.сектора, где сделали отличную админку, кучу интересных вещей, использовали на многих проектах, но на версии php выше 5.6 — все наработки стали legacy, вышел новый ZF, с новым подходом. В итоге отложили на полку, т.к. делать update некому и нет ресурсов.
3. Пришел изначально простой проект, который должен со временем масштабироваться до сложного. Решил попробовать сделать без фреймворка. Собрал из разных библиотек(маршрутизация, ORM, ...), накидал свои классы. Никаких особых сложностей при разработке не возникло, т.к. двигался от простого к сложному и знал как будет развиваться приложение. Но, есть одно но — мне всё понятно и просто, т.к. написал всё я. Как потом будет ориентироваться другой разработчик — вот тут возникает жирный вопрос, потому как сейчас там много всего. А документации нет. Есть только комментарии в коде, phpDoc и readme. Получается, следующий разраб будет дописывать по-своему, и так далее. Плюс я ограничен уровнем своей компетенции и могу какие-то вещи не учесть, где во фреймворке это было бы из коробки.
Compolomus
23.03.2021 08:23Главное если пишешь свой фреймворк, или берешь готовый, чтоб в нем было минимальное количество зависимостей в ядре. Чтоб была какая то структура, договоренность, а далее просто обвес. Если рассматривать фреймворк mvc, то m и v можно вообще не брать во внимание, сделать пачку интерфейсов и загрузчик по psr4. Подобное что то было в зенде, но там конфиг адовый, есть стандартные штуки для моделей или вьюхи, но они не привязаны. Не важно какой фронт или бэк будет, плюс вагон кирпичей с реализациями. Ну а интерфейсы позволят вообще все детали заменить, а если детали по psr, все становиться ещё проще. Можешь сделать консольное без вида, или api с json. Или взять любой шаблонизатор и какой нибудь js фреймворк. А хэлперы из фреймворков лучше не брать, так как они зачастую не общие. Писать самому их, либо брать отдельные
dmx00
23.03.2021 08:23Если Вы сомневаетесь нужен ли Вам фреймворк, то он Вам точно нужен, т.к. у Вас не хватает экспертизы в вопросе, иначе бы сомнений не было. Даже если Вы уверены что фреймворк не нужен это может быть ошибкой. На мой взгляд этим вопросом чаще всего задаются новички, для них ответ однозначный: «нужен» и нет это не означает что нужно «программировать на фреймворке» т.е. изучать только фреймворк, и не изучать возможности языка программирования. Попробовать написать свой фреймворк полезно, начинаешь понимать почему те или иные решение были взяты в известных фреймворках, но делать такие эксперименты нужно на «второстепенных» проектах, которые переписать или выкинуть не составит большого труда.
AlekVeritov
23.03.2021 08:23Мне кажется, и в статье, и в комментариях забыли упомянуть про ещё один немаловажный аргумент в рассматриваемом вопросе — получая в своём проекте все озвученные преимущества фреймворка вы получаете также и все его уязвимости. А они есть в любом фреймворке, какими бы талантливыми не были его разработчики (укажите на фреймворк без уязвимостей, если я ошибаюсь). Причём количество людей, ищущих эти уязвимости, прямо пропорционально популярности фреймворка. Т.о., имея уникальную разработку, вы повышаете трудозатраты на взлом конкретно вашего проекта, т.к. известных уязвимостей найти в сети не получится. Соответственно, существенно понижается привлекательность взлома, т.к. даже при успехе злоумышленник будет иметь один взломанный проект, а не условно "все сайты на фреймворке Х". Проще говоря, надо иметь очень популярный проект, чтобы начали ломать вас ради вас.
Проблема отчасти решаема обновлениями фреймворка, но это несёт сопутствующие накладные расходы (в статье это упомянуто). Считаю, это довольно весомый аргумент при разработке
популярногокоммерческого продукта.
vsh797
23.03.2021 08:23имея уникальную разработку, вы повышаете трудозатраты на взлом конкретно вашего проекта
При условии, что вы в своем решении не создадите проблем с безопасностью, которые в популярном фреймворке решены давно, в т.ч. и на уровне архитектуры и лучших практик.
AlekVeritov
23.03.2021 08:23Даже если создадите проблемы с безопасностью, то надо чтобы кто-то их начал целенаправленно искать, об этом речь. Есть мнение, что какие-нибудь условные самописные региональные интернет-магазины годами живут с
ужаснымидырами в безопасности, как неуловимый Джо из анекдота. Один из первых пунктов кулхацкерского чеклиста — проверить наличие известных уязвимостей у используемого софта, в таких случаях часто становится единственным, ибо дальше лень и нафиг надо.
Про уровень архитектуры да, безусловно, поэтому озвученное мной это только аргумент, а не исчерпывающая причина отказа. В каждом случае надо взвешивать все за и против.
Noble-Bastard
23.03.2021 08:23Я — начинающий PHP разработчик. И я, пока не изучил ни один фреймворк, хотя кто-либо кто обладал бы такими же знаниями как я, уже начинают и вовсю используют их. И я только сейчас начал смотреть в сторону фреймворков(но так и не определился с первой любовью или с первым врагом). Знакомые, такие же новички как я, говорят мне, почему же я не беру сторону фреймворков, так как мои знания уже давно как позволяют написать свой мини-фреймворк или поизучать другой фреймворк чтобы сделать на нем проект. Я просто не отвечаю им. Но, сейчас думаю самое время)
У меня в памяти есть один знакомый, начали мы вместе. Нам один прекрасный человек рассказал о фреймворках написанных на PHP и что мы буквально за несколько дней можем создать крутой сайтик-блог или даже форум. И, я и мой знакомый воодушевились этим. Он сказал что есть вот такие вот фреймворки, и рассказал что нужно знать хотя бы основы PHP чтобы писать на их основе. Он порекомендовал нам видео-ролики на ютубе по основам PHP(самые-самые основы, переменные, функции, циклы, условия и т.д.). За неделю или даже меньше мы уже изучили все основы и посмотрели все видео. Мы также узнали что есть мир ООП и процедурного программирования, в котором мы писали. И мы, начали смотреть на сторону фреймворков, так как ООП на тот момент было из ряда выходящего вон для обычных школьников. Я посмотрел видео ролик на ютубе где один человек рассказывал что фреймворки портят код и начинающих программистов и скинул видос знакомому. Он посмотрел и просто сказал что тот дядя кхм., кхм… Пожалуй не буду выражаться. Но, я все же прислушался к словам того дяди, так как я понимал что мои знания поверхностны. И в итоге я повременил с изучением фреймворков. Мой друг пошел изучать Laravel, а я пошел по пути чистого ООП. В итоге, он за неделю-две создал свой сайт-блог, полностью сам читая документацию и подсматривая видео-ролики. А я все внедрялся в тему чистого ООП, даже попробовал на C# что-то да сделать. Он, за время написания своего сайтика тысячу и один раз спрашивал банальные вопросы по типу что такое объект, как создавать его инстанс, помоги пожалуйста подключать базу данных. Также он вообще не знал что и какой функционал выполняет та или иная фича реализованная в его фреймворке. Просто следовал документации и видео. И я ему помогал в обмен на домашку по алгебре. Также, узнал что есть телеграм каналы и форумы где можно задавать вопросы и скинул ему ссылку на них. В итоге еще через несколько недель он хотел пойти на фриланс. Я сказал ему, мол, мы только месяца два ток изучаем, какой еще фриланс? Ты кроме своего фреймворка ничего то не видел!(Возможно для кого-то 2 месяца это большой срок, но мы — школьники, и изучать технологии приходилось только по вечерам или даже через определенный промежуток времени) В итоге, через месяц-два он все таки понял что ему трудно писать простые базовые вещи без гугла и помощи(на фриланс так и не ушел). И он пока забросил тему с фреймворками и теперь догоняет меня).
Мораль сей истории такова. Если вы, начинающий разработчик, то не смотрите в сторону фреймворков хотя бы 3-4 месяца пока не изучите самые азы на достаточном уровне чтобы понимать устройство фреймворков. А потом, можете всего за неделю освоить новую технологию и сделать свой стартап всего за 2 недели :D
Это лишь краткая история, возможно для кого-то окажется абсурдом, но для кого-то это может быть и полезно.SamDark Автор
23.03.2021 08:23Нормальная история. Фреймворк всё-таки подразумевает что знакомство с основами пройдено.
vsh797
23.03.2021 08:23Ваш товарищ, конечно, слишком рано за фреймворк взялся. Но после того, как начинающий освоиться в языке, ему, как мне кажется, стоит выучить один из популярных фреймворков. Во-первых он в ходе изучения столкнется с множеством паттернов, концепций и инструментов. А во-вторых большая часть современной разработки все-таки идет с фреймворком. Пусть даже вручную собранным из различных компонентов.
Scf
Всё это делается спецализированными библиотеками, которые комбинируются в приложение.
По моему опыту, есть только 3 причины использовать фреймворки:
avraam_linkoln
Еще ни разу не встречал проект в котором не использовались бы фреймворки и при этом что бы это не был говнокод.
modjo
Обычно фреймворки не любят низкоквалифицированные специалисты, для которых он представляется черным ящиком и работа с ним вызывает трудности ввиду не понимания его устройства.
coh
Не все так однозначно.
В узкоспециализированных задачах, где важна производительность фреймворк может быть обузой.
Роберт Мартин про фреймворки: youtu.be/2dKZ-dWaCiU?t=4032
Низкоквалифицированные сотрудники тоже любят фреймворки, чаще всего 1 конкретный, бывает не умеют писать SQL запросы руками и не знают базовых вещей типа: как работает автозагрузка, как работать с PDO и прочее.
Бывают проекты в которых вообще нет смысла велосипедить, взял любой фреймворк и накидал приложение за пару дней. Та же история в проектах с десятками и сотнями программистов, где нужны общие практики.
Есть проекты которые живут 7,10 и более лет (ни один фреймворк не переживает такой срок, превращаясь в легаси с устаревшими подходами), а миграция на новую версию может грозить полным переписыванием.
Scf
У меня такой же опыт. Начинал свою карьеру с JSF+Hibernate+Spring, не зная ни джаваскрипта, ни толком SQL, ни умея проектировать и структурировать код. И, соответственно, тратил огромное количество времени, пытаясь понять, почему оно работает не так.
ElisDN
И низкоквалифицированные, и высококвалифицированные.
Низкоквалифицированные специалисты не используют, так как ещё не дошли до их понимания.
А высококвалифицированные специалисты не используют, так как досконально знают их устройство и с этим опытом теперь способны собрать индивидуальный проект из нужных компонентов без оверхэда готового фреймворка.
panteleymonov
Гайды и документации в фреймворках как раз для низкоквалифицированных. Те низкоквалифицированные о которых вы говорите — это скорее совсем пользователи, не специалисты. В 90 и 2000 любой мог влет освоить фреймворк с документацией под рукой, но сейчас видимо появилась новая категория? Как такой низкоквалифицированный вообще что либо напишет кроме «hello world»? Любой язык имеет за собой базовый фреймворк и любая реализация чего либо требует хоть какого-то API.
Высококвалифицированные специалисты также используют фреймворки определенного уровня API. Не использовать фреймворки это равносильно написанию собственной ос вместе с языком. Так или иначе алгоритмические фреймворки или их части легко заменяются на самописные. Понятие фреймворка гораздо шире чем просто отдельная дополнительная тулза с типами данных для разработки. Android SDK, например, это тоже фреймворк. А уж знание С++ автоматом подразумевает знание STL — базовый фреймворк. Тоже самое касается и других языков. И чтоб избавиться от этих базовых фреймворков, приходиться не мало костылей написать, чтобы сам язык не потерял свою функциональность.
SamDark Автор
Я бы так не сказал. Тот же Android SDK без документации было бы очень неприятно использовать.
ZurgInq
Точно так же можно сказать, что фреймворки любят низкоквалифицированные специалисты, которые не понимают как они работают и что крутится под капотом и поэтому не способны решать задачи без фрэймворков.
Любой фреймворк — это в первую очередь искусственные ограничения. Где то они нужны, где то нет и только мешают. Когда фреймворк начинает вставлять палки в колёса больше, чем помогает, нормальные специалисты с готового фреймворка переходят на набор нужных библиотек под конкретную задачу.
pbatanov
И вот здесь очень четко можно проследить отличие хороших компонентных фреймворков от посредственных. В хороших можно выкинуть практически любую деталь и заменить на другую либу и\или самопис, который менее функционален но более заточен под конкретно ваш кейс и решает конкретно вашу проблему оптимальней (критерий зависит от постановки вопроса, это может быть быстрей\проще\понятней).
Например приложение на фуллстек симфони позволяет выкинуть практически что угодно. Хочешь свой роутинг — легко. Другой ORM\DBAL? запросто! Технически реально поменять даже имплементацию контейнера. Это потребует ручной загрузки бандлов, т.к. многие из них пользуются тем, что есть стадия компиляции, но это в целом реально.
SamDark Автор
А как же отсутствие желания писать документацию, учить новых членов команды, тратить время чтобы нормально собрать вместе N библиотек?
Scf
Код для "склеивания" существующих библиотек, как правило, невелик по объему и сильного погружения не требует, отдельные библиотеки хорошо документированы и просты в понимании. Сбор библиотек в приложение — да, инвестиция, но с хорошим возвратом.
SamDark Автор
Относительно кода самих библиотек да, невелик. Но сам по себе значителен и, чаще всего, не документирован и просит поддержки. То есть тратим время на дополнительную документацию, на вот этот код, на его поддержку (ту же безопасность поддерживать), на обучение ему новых сотрудников. А плюсы где?
FanatPHP
Те же овоиды, вид в профиль.
Никто не мешает использовать готовую сборку "специализированных библиотек". Проверенную на соместимость, с гарантированным LTS, с активным сообществом и примерно миллионом других плюшек.
При том что формально фреймворк вполне подходит под определение, поскольку и состоит из этих самых "специализированных" библиотек. Так что я не понимаю этого снобизма.
Ну то есть может быть у вас в Джаве это не так, но те фреймворки, о которых говорят Саша и Маттиас — это именно что модульные сборки отдельных библиотек. Роутер, ОРМ, шаблонизатор, валидатор, стандартные хелперы. Всё это можно поставить отдельно, но для среднестатистического сайта все равно нужно в сборке. Которую опять же можно вручную подрихтовать
Scf
Да, в джаве так не принято. "Фреймворк" в таком определении выглядит приемлемо, да. Наверное, это скорее шаблон приложения, чем фреймворк?
FanatPHP
Ну кстати да, я что-то не подумал, что еще недавно в РНР все было именно так. Везде были монолитные фреймворки — Codeigniter; Cake; Yii и Симфони 1 и 2 версий. Но 3-я Симфони изначально задумывалась как набор отдельных модулей, имеющих при этом стандартную сборку. С тех пор эта модульность уходит все дальше и дальше, и в какой-то мере современный "фреймворк" — это скорее набор модулей. Который, тем не менее, предлагает несколько вариантов стандартных сборок. Которые да, можно в какой-то мере называть шаблонами приложений.
При этом один фреймворк может свободно использовать десяток модулей от другого, плюс еще десяток совсем отдельных библиотек. Которые при желании можно поменять на другие. Но обычно народ не заморачивается поскольку обучающие видео снимаются про стандартную сборку.