Копаем глубже в Feature-Sliced Design / Александр Моргунов
ฝัง
- เผยแพร่เมื่อ 27 ก.ย. 2024
- Это Александр Моргунов из Samokat.tech и его доклад на «Я💛Фронтенд 2024» - нашей главной фронтенд-конференции. На ней мы обсудили, как делать удобные интерфейсы, использовать популярные и не очень инструменты, правильно относиться к себе и сообществу и строить карьеру.
В своём докладе Александр расскажет об архитектурной методологии Feature-Sliced Design (FSD). Архитектура - это всегда сложно: много различных терминов и практик, которые не всегда получается однозначно разобрать. А некоторые подходы способны даже навредить проекту. Александр кратко разберёт FSD, поделится своим опытом его использования и раскроет некоторые моменты, не описанные в его документации. И ответит на главный вопрос: нужен вам FSD или нет?
Всю информацию о мероприятиях Яндекса можно найти здесь: events.yandex.ru/
Подписывайтесь на телеграм-канал о жизни фронтендеров Яндекса: t.me/yandex4fr...
в сотни раз лучше и понятней объяснён FDS, чем в самой его документации ) спс.
Самая большая проблема фсд, это субъективщина, каждый в команде понимает по своему. Плюс код размазывается тонким слоем по проекту, совершенно без причины. Если мы что-то переиспользуем, только тогда это надо выносить в энтити или фичу, в остальных же случаев это карго-культ.
Иногда данная субъективщина играет на пользу) в общем то самими разработчиками FSD закладывалось то что каждая команда может подстроить методологию по своему, главное что бы кодеры в контексте одной команды понимали эти пастулаты)
@@yunglocokid1457 их нельзя понять, у них нет определения
Так потому что этот фсд буквально наркоман сова выдумал
@@yunglocokid1457 а в чем тогда плюс методологии, если мы опять пришли к тому, что все делают все по своему?
@@yunglocokid1457 "...главное что бы кодеры в контексте одной команды понимали эти пастулаты" тут многовековые баталии идут что лучше react/vue/angular, теперь еще и срач в команде будет что в Entities, а что в Features, и даже когда все устанут и смеряться, придет новый чел из другой компании в которой использовали fsd но другой, и начнется все сначала. Как и любая методология все сводится "пиши код хорошо, плохо не пиши", так что без четких правил это лишь опыт лида натянутый на какие-то правила с исключениями основанными на опыте, уйдет лид, потихоньку наступит трэш) можно было и не создавать сайт под fisting-suka-design
если у каждого свое понимание фсд - то значит есть проблема с методологией.
обратная сторона гибкости
Александр классный докладчик! Просмотрел до конца. Но мне до сих пор не понятно, какие проблемы решает FSD на фронте, что делает проще, легче и быстрей. Ощущение, что этот FSD ради FSD и при этом довольно трудно ему следовать ибо концепция довольно субъективна
Судя по видео, FSD не решает проблемы, а создает их. И докладчик 45 минут объясняет нам, как продолжать ехать на велосипеде после того, как мы сами себе вставили палку в колесо.
Возьмите какое то свое приложение которое вы хорошо знаете. И соберите его по FSD, все вопросы будут закрыты, зачем и почему. Я раньше тоже думал надо ли оно мне. Оказалось что надо.
@@xxxxxxxeeeeeeeeee ну получается это проблема человека который понял тогда, методология то тут причем?) Но я и не спорю, что это какая то серебряная пуля, совсем нет. Мне наоборот проще по старинке работать, и гемороя меньше.
@@lolhohol возьмите готовое блюдо, выбросите его и съешьте говно и все вопросы будут закрыты. Я раньше тоже думал надо ли оно мне. Оказалось что надо.
@@gh8499ничего не понятно, но очень интересно
Что плохого в модульной архитектуре на подобии той, что используется в Ангуляр проектах? FSD по сравнению с ней гораздо сложнее;( В одной крупной компании придумали, все копируют, совершают ошибки, сам FSD частенько конфликтует с другими библиотеками и фреймворками, при чем даже с документацией в ней сложно разобраться и по итогу проект только еще сложнее становится.
тем что даже в ангуляре в модульной архитектуре можно довольно хорошо поговнокодить. fsd ложится хорошо под любую архитектуру будь то react, angular или vue, и вообще никак не конфликтует. В ангуляре не используя никакой методологии, можно наклепать модулей, и все равно иметь зависимости между модулями, потому что некоторые вещи с ростом проекта, как правило, начинают использоваться в нескольких модулях. можно вынести все в shared, тогда будет у тебя вроде как переиспользуемый код с одной стороны, а с другой стороны у этот код будет содержать бизнес логику, а так как еще он используется в разных модулях, наверняка он еще будет меняться под новые какие то требования, а это уже нарушает обычный SOLID. методология FSD совершенствуется, потому что общество растет, вопросов становится больше, и следовательно и ответов на эти вопросы. FSD требует не документацию, а целую книгу, потому что это архитектурная методология. Строгих инструкций тут быть не может. Ты также не найдешь документацию по DDD, нужно прочитать как минимум одну книгу, и поработать с каким то проектом, чтобы понять что да как.
Наговнокодить можно где угодно, и fsd тут не исключение.) А "кривой" концепт fsd, который сами авторы не могут описать в документации, не слабо увеличивают эту вероятность.)
@@SuhushinAS есть телега, есть сообщество, есть бот который поможет ответить на многие вопросы, есть множество примеров... остальное уже в ответственности разраба
@@valikirr В ответственности разработчика - выбрать архитектуру, которая понятна, без сидения в чатах и имеет все те же преимущества)
@@SuhushinAS здрасьте. тогда давайте поговорим о бэкенде. попробуйте разрабатывать приложение на DDD не прочитав хотя бы одну книгу по DDD. а в отличие от FSD, такой вот официальной документации по DDD вообще нет. А даже прочитав книгу, там появится столько вопросов, что придется еще и доклады разные послушать, и с опытными разрабами проконсультироваться, и т.д. Архитектура вообще по своей сути не углубляется в тонкие детали реализации. Если вы найдете такую волшебную архитектуру и документацию к ней, где все сразу будет понятно и разобрано до мелочей, дайте знать.
На мой взгляд, бесполезный доклад, продающий бесполезную FSD-методологию, которая только в теории звучит хорошо, а на практике создает только проблемы с неудобным "размазыванием" кодовой базы по многим файлам, созданием излишних сущностей, папок, файлов и смысловых противоречий даже в простом проекте.
Кому FSD упростил жизнь в боевом проекте?
Напишите, пожалуйста, ответ на этот комментарий.
Я пробовал FSD и ужаснулся от его бесполезности для решения реальных проблем сложности разработки любых frontend-проектов.
Такое чувство что люди из бэкенда пытаются писать фронт, и пытаются писать бэк на фронтЕ.
Какая архитектура тогда полезна ? FSD не заставляет вас создавать сущности, по сути только 3 слоя обязательны(app, pages, shared), можно все делать в папке pages, и выносить общие компоненты в shared.
@@BorisEdigarian Любая кастомная модульная архитектура, удобная команде или группе команд.
По моему, это очевидно, разве нет?
Если, как вы сказали "можно все делать в папке pages, и выносить общие компоненты в shared.", то где тут FSD, подразумевающий наличие Entities, Features и прочие излишние абстракции?
В вашем описании не прослеживается какая-либо архитектурная методология, а я спросил про то, кому FSD упростил жизнь в РЕАЛЬНОМ ПРОДЕ.
Шош, по итогу просмотра, имеем
1. на правило крос импорта в Widgets забили,
2. на правило крос импорта в Entities забили,
3. Features использовали не верно, но потом вроде верно, но может и не верно
4. кастомные подслои )))
самое частое что я слышал в докладе "...опять же методология это запрещает, но мы вот тут столкнулись, и придумали..."
я предлагаю свою:
1. создаем папку src/
2. плохо код не пишем, а пишем хорошо
мне кажется, что она даже чуточку получше будет
Кстати, неплохой доклад.
Я думал он, как адепт ФСД, будет рассказывать как ОЧЕНЬ важно все раскладывать по нужным папочкам, а он практически сразу сказал про то что, ну вот не работает на больших проектах.
Свой линтер и настойчивость команды ФСД в упоре на "чистый" ФСД - это не очень хороший сигнал.
Вообще, конечно, хорошая идея держать структуру папочек максимально плоской и иметь хоть какую-то конвенцию по их неймингу. Но по мне так ФСД - это чисто русскоязычная тема, за которой не стоит какой-то реальной технологии, а конвенцию папочек я и сам вам придумаю или пойму (если ее писали с капелькой здравого смысла).
Я бы не хотел работать в команде с жесткими адептами ФСД.
Мандец, этот FSD такой запутанный))
Я пытаюсь внедрить FSD на всех своих проектах уже как год, но сейчас понимаю, что это оверрейтед методология) Даже в самых базовых случаях приходится нарушать привила (например кросс-импорты). Надо придумывать что-то другое
Докладчик задел тему про получение моделей от бекенда. Для этого лучше использовать кодген опенапи или графкл, ну или иные инструменты которые для этого подходят. Странно, что не сказал, когда упоминал
+
для одностраничника ОК
А, это ваши люди наезжают на прохожих (и на меня тоже) на тротуарах?! Уже минус
Че за эпилепсия у монтажера.
Докладчик рассказывает новые штуки опираясь на слайд, нам покажут зал, покажут докладчика, покажут взгляд под углом, но не сам слайд 🤦♀️
Некоторые слайды в кадре появляются буквально на 2 секунды, даже прочитать не успеваешь как уже меняются. И это опять же гениальное чувство монтажника.
Прекрасный доклад