Pull to refresh

Comments 32

Фреймворк должен помочь вам:
[список требований]

Всё это делается спецализированными библиотеками, которые комбинируются в приложение.


По моему опыту, есть только 3 причины использовать фреймворки:


  • Недоступность квалифицированных разработчиков
  • Низкие требования к качеству приложения (размер, быстродействие, нестандартные фичи)
  • Прототипирование
Еще ни разу не встречал проект в котором не использовались бы фреймворки и при этом что бы это не был говнокод.

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

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

Роберт Мартин про фреймворки: youtu.be/2dKZ-dWaCiU?t=4032

Низкоквалифицированные сотрудники тоже любят фреймворки, чаще всего 1 конкретный, бывает не умеют писать SQL запросы руками и не знают базовых вещей типа: как работает автозагрузка, как работать с PDO и прочее.

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

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

У меня такой же опыт. Начинал свою карьеру с JSF+Hibernate+Spring, не зная ни джаваскрипта, ни толком SQL, ни умея проектировать и структурировать код. И, соответственно, тратил огромное количество времени, пытаясь понять, почему оно работает не так.

И низкоквалифицированные, и высококвалифицированные.


Низкоквалифицированные специалисты не используют, так как ещё не дошли до их понимания.


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

Гайды и документации в фреймворках как раз для низкоквалифицированных. Те низкоквалифицированные о которых вы говорите — это скорее совсем пользователи, не специалисты. В 90 и 2000 любой мог влет освоить фреймворк с документацией под рукой, но сейчас видимо появилась новая категория? Как такой низкоквалифицированный вообще что либо напишет кроме «hello world»? Любой язык имеет за собой базовый фреймворк и любая реализация чего либо требует хоть какого-то API.

Высококвалифицированные специалисты также используют фреймворки определенного уровня API. Не использовать фреймворки это равносильно написанию собственной ос вместе с языком. Так или иначе алгоритмические фреймворки или их части легко заменяются на самописные. Понятие фреймворка гораздо шире чем просто отдельная дополнительная тулза с типами данных для разработки. Android SDK, например, это тоже фреймворк. А уж знание С++ автоматом подразумевает знание STL — базовый фреймворк. Тоже самое касается и других языков. И чтоб избавиться от этих базовых фреймворков, приходиться не мало костылей написать, чтобы сам язык не потерял свою функциональность.
Гайды и документации в фреймворках как раз для низкоквалифицированных

Я бы так не сказал. Тот же Android SDK без документации было бы очень неприятно использовать.

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

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

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

Например приложение на фуллстек симфони позволяет выкинуть практически что угодно. Хочешь свой роутинг — легко. Другой ORM\DBAL? запросто! Технически реально поменять даже имплементацию контейнера. Это потребует ручной загрузки бандлов, т.к. многие из них пользуются тем, что есть стадия компиляции, но это в целом реально.

А как же отсутствие желания писать документацию, учить новых членов команды, тратить время чтобы нормально собрать вместе N библиотек?

Код для "склеивания" существующих библиотек, как правило, невелик по объему и сильного погружения не требует, отдельные библиотеки хорошо документированы и просты в понимании. Сбор библиотек в приложение — да, инвестиция, но с хорошим возвратом.

Относительно кода самих библиотек да, невелик. Но сам по себе значителен и, чаще всего, не документирован и просит поддержки. То есть тратим время на дополнительную документацию, на вот этот код, на его поддержку (ту же безопасность поддерживать), на обучение ему новых сотрудников. А плюсы где?

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


Ну то есть может быть у вас в Джаве это не так, но те фреймворки, о которых говорят Саша и Маттиас — это именно что модульные сборки отдельных библиотек. Роутер, ОРМ, шаблонизатор, валидатор, стандартные хелперы. Всё это можно поставить отдельно, но для среднестатистического сайта все равно нужно в сборке. Которую опять же можно вручную подрихтовать

Да, в джаве так не принято. "Фреймворк" в таком определении выглядит приемлемо, да. Наверное, это скорее шаблон приложения, чем фреймворк?

Ну кстати да, я что-то не подумал, что еще недавно в РНР все было именно так. Везде были монолитные фреймворки — Codeigniter; Cake; Yii и Симфони 1 и 2 версий. Но 3-я Симфони изначально задумывалась как набор отдельных модулей, имеющих при этом стандартную сборку. С тех пор эта модульность уходит все дальше и дальше, и в какой-то мере современный "фреймворк" — это скорее набор модулей. Который, тем не менее, предлагает несколько вариантов стандартных сборок. Которые да, можно в какой-то мере называть шаблонами приложений.
При этом один фреймворк может свободно использовать десяток модулей от другого, плюс еще десяток совсем отдельных библиотек. Которые при желании можно поменять на другие. Но обычно народ не заморачивается поскольку обучающие видео снимаются про стандартную сборку.

Convention over configuration, так как фреймворк — это не только набор инструментов, но и заранее известные договорённости.
По моему опыту, использование фреймворков уменьшает время onboard`инга нового сотрудника с 2-3 месяцев до 1-2 недель.

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

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


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

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

Даже с фреймворком clean code никто не отменял. Накидывайте вопросов, отвечу на все.


нужен ли фреймворк

Нужен если у вас нет тучи времени и желания собирать свой, писать к нему документацию и поддерживать его. Если есть — тут уже вопрос. Нужно считать.


а если готовый, то какой и тд.

Тут на вкус и цвет и под задачу. Лучше на конкретном примере.

1. Заказчик может сказать, что им нужен надежный фреймворк, т.е. не битрикс, а symfony или ZendFramework, остальное их не особо волнует. Или что-то модное- современное.
2. На основе ZendFramework сделали своё для корп.сектора, где сделали отличную админку, кучу интересных вещей, использовали на многих проектах, но на версии php выше 5.6 — все наработки стали legacy, вышел новый ZF, с новым подходом. В итоге отложили на полку, т.к. делать update некому и нет ресурсов.
3. Пришел изначально простой проект, который должен со временем масштабироваться до сложного. Решил попробовать сделать без фреймворка. Собрал из разных библиотек(маршрутизация, ORM, ...), накидал свои классы. Никаких особых сложностей при разработке не возникло, т.к. двигался от простого к сложному и знал как будет развиваться приложение. Но, есть одно но — мне всё понятно и просто, т.к. написал всё я. Как потом будет ориентироваться другой разработчик — вот тут возникает жирный вопрос, потому как сейчас там много всего. А документации нет. Есть только комментарии в коде, phpDoc и readme. Получается, следующий разраб будет дописывать по-своему, и так далее. Плюс я ограничен уровнем своей компетенции и могу какие-то вещи не учесть, где во фреймворке это было бы из коробки.

Главное если пишешь свой фреймворк, или берешь готовый, чтоб в нем было минимальное количество зависимостей в ядре. Чтоб была какая то структура, договоренность, а далее просто обвес. Если рассматривать фреймворк mvc, то m и v можно вообще не брать во внимание, сделать пачку интерфейсов и загрузчик по psr4. Подобное что то было в зенде, но там конфиг адовый, есть стандартные штуки для моделей или вьюхи, но они не привязаны. Не важно какой фронт или бэк будет, плюс вагон кирпичей с реализациями. Ну а интерфейсы позволят вообще все детали заменить, а если детали по psr, все становиться ещё проще. Можешь сделать консольное без вида, или api с json. Или взять любой шаблонизатор и какой нибудь js фреймворк. А хэлперы из фреймворков лучше не брать, так как они зачастую не общие. Писать самому их, либо брать отдельные

UFO just landed and posted this here
Если Вы сомневаетесь нужен ли Вам фреймворк, то он Вам точно нужен, т.к. у Вас не хватает экспертизы в вопросе, иначе бы сомнений не было. Даже если Вы уверены что фреймворк не нужен это может быть ошибкой. На мой взгляд этим вопросом чаще всего задаются новички, для них ответ однозначный: «нужен» и нет это не означает что нужно «программировать на фреймворке» т.е. изучать только фреймворк, и не изучать возможности языка программирования. Попробовать написать свой фреймворк полезно, начинаешь понимать почему те или иные решение были взяты в известных фреймворках, но делать такие эксперименты нужно на «второстепенных» проектах, которые переписать или выкинуть не составит большого труда.

Мне кажется, и в статье, и в комментариях забыли упомянуть про ещё один немаловажный аргумент в рассматриваемом вопросе — получая в своём проекте все озвученные преимущества фреймворка вы получаете также и все его уязвимости. А они есть в любом фреймворке, какими бы талантливыми не были его разработчики (укажите на фреймворк без уязвимостей, если я ошибаюсь). Причём количество людей, ищущих эти уязвимости, прямо пропорционально популярности фреймворка. Т.о., имея уникальную разработку, вы повышаете трудозатраты на взлом конкретно вашего проекта, т.к. известных уязвимостей найти в сети не получится. Соответственно, существенно понижается привлекательность взлома, т.к. даже при успехе злоумышленник будет иметь один взломанный проект, а не условно "все сайты на фреймворке Х". Проще говоря, надо иметь очень популярный проект, чтобы начали ломать вас ради вас.


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

имея уникальную разработку, вы повышаете трудозатраты на взлом конкретно вашего проекта

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

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


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

Я — начинающий PHP разработчик. И я, пока не изучил ни один фреймворк, хотя кто-либо кто обладал бы такими же знаниями как я, уже начинают и вовсю используют их. И я только сейчас начал смотреть в сторону фреймворков(но так и не определился с первой любовью или с первым врагом). Знакомые, такие же новички как я, говорят мне, почему же я не беру сторону фреймворков, так как мои знания уже давно как позволяют написать свой мини-фреймворк или поизучать другой фреймворк чтобы сделать на нем проект. Я просто не отвечаю им. Но, сейчас думаю самое время)

У меня в памяти есть один знакомый, начали мы вместе. Нам один прекрасный человек рассказал о фреймворках написанных на PHP и что мы буквально за несколько дней можем создать крутой сайтик-блог или даже форум. И, я и мой знакомый воодушевились этим. Он сказал что есть вот такие вот фреймворки, и рассказал что нужно знать хотя бы основы PHP чтобы писать на их основе. Он порекомендовал нам видео-ролики на ютубе по основам PHP(самые-самые основы, переменные, функции, циклы, условия и т.д.). За неделю или даже меньше мы уже изучили все основы и посмотрели все видео. Мы также узнали что есть мир ООП и процедурного программирования, в котором мы писали. И мы, начали смотреть на сторону фреймворков, так как ООП на тот момент было из ряда выходящего вон для обычных школьников. Я посмотрел видео ролик на ютубе где один человек рассказывал что фреймворки портят код и начинающих программистов и скинул видос знакомому. Он посмотрел и просто сказал что тот дядя кхм., кхм… Пожалуй не буду выражаться. Но, я все же прислушался к словам того дяди, так как я понимал что мои знания поверхностны. И в итоге я повременил с изучением фреймворков. Мой друг пошел изучать Laravel, а я пошел по пути чистого ООП. В итоге, он за неделю-две создал свой сайт-блог, полностью сам читая документацию и подсматривая видео-ролики. А я все внедрялся в тему чистого ООП, даже попробовал на C# что-то да сделать. Он, за время написания своего сайтика тысячу и один раз спрашивал банальные вопросы по типу что такое объект, как создавать его инстанс, помоги пожалуйста подключать базу данных. Также он вообще не знал что и какой функционал выполняет та или иная фича реализованная в его фреймворке. Просто следовал документации и видео. И я ему помогал в обмен на домашку по алгебре. Также, узнал что есть телеграм каналы и форумы где можно задавать вопросы и скинул ему ссылку на них. В итоге еще через несколько недель он хотел пойти на фриланс. Я сказал ему, мол, мы только месяца два ток изучаем, какой еще фриланс? Ты кроме своего фреймворка ничего то не видел!(Возможно для кого-то 2 месяца это большой срок, но мы — школьники, и изучать технологии приходилось только по вечерам или даже через определенный промежуток времени) В итоге, через месяц-два он все таки понял что ему трудно писать простые базовые вещи без гугла и помощи(на фриланс так и не ушел). И он пока забросил тему с фреймворками и теперь догоняет меня).

Мораль сей истории такова. Если вы, начинающий разработчик, то не смотрите в сторону фреймворков хотя бы 3-4 месяца пока не изучите самые азы на достаточном уровне чтобы понимать устройство фреймворков. А потом, можете всего за неделю освоить новую технологию и сделать свой стартап всего за 2 недели :D

Это лишь краткая история, возможно для кого-то окажется абсурдом, но для кого-то это может быть и полезно.

Нормальная история. Фреймворк всё-таки подразумевает что знакомство с основами пройдено.

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

Sign up to leave a comment.