Копаем глубже в Feature-Sliced Design / Александр Моргунов

Рет қаралды 14,042

Күн бұрын

Пікірлер: 60

@КапитанТеребонька-з5и 3 ай бұрын

Шош, по итогу просмотра, имеем 1. на правило крос импорта в Widgets забили, 2. на правило крос импорта в Entities забили, 3. Features использовали не верно, но потом вроде верно, но может и не верно 4. кастомные подслои ))) самое частое что я слышал в докладе "...опять же методология это запрещает, но мы вот тут столкнулись, и придумали..." я предлагаю свою: 1. создаем папку src/ 2. плохо код не пишем, а пишем хорошо мне кажется, что она даже чуточку получше будет

@DuskyBrumm 16 күн бұрын

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

@kromus 6 ай бұрын

в сотни раз лучше и понятней объяснён FDS, чем в самой его документации ) спс.

@vgsnva 6 ай бұрын

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

@yunglocokid1457 6 ай бұрын

Иногда данная субъективщина играет на пользу) в общем то самими разработчиками FSD закладывалось то что каждая команда может подстроить методологию по своему, главное что бы кодеры в контексте одной команды понимали эти пастулаты)

@Евгений-э1ц3щ 6 ай бұрын

@@yunglocokid1457 их нельзя понять, у них нет определения

@radiofedor 6 ай бұрын

Так потому что этот фсд буквально наркоман сова выдумал

@gh8499 4 ай бұрын

@@yunglocokid1457 а в чем тогда плюс методологии, если мы опять пришли к тому, что все делают все по своему?

@КапитанТеребонька-з5и 3 ай бұрын

@@yunglocokid1457 "...главное что бы кодеры в контексте одной команды понимали эти пастулаты" тут многовековые баталии идут что лучше react/vue/angular, теперь еще и срач в команде будет что в Entities, а что в Features, и даже когда все устанут и смеряться, придет новый чел из другой компании в которой использовали fsd но другой, и начнется все сначала. Как и любая методология все сводится "пиши код хорошо, плохо не пиши", так что без четких правил это лишь опыт лида натянутый на какие-то правила с исключениями основанными на опыте, уйдет лид, потихоньку наступит трэш) можно было и не создавать сайт под fisting-suka-design

@bedbotov 5 ай бұрын

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

@NikVolkov 5 ай бұрын

обратная сторона гибкости

@sashaulycode 6 күн бұрын

00:14 Введение в методологию FSD 02:03 Архитектура и паттерны 03:36 Что такое FSD 04:57 Проблемы и преимущества FSD 06:54 Основные концепции FSD 09:26 Проектирование с FSD 11:21 Модули и сущности 12:22 Доменные и инфраструктурные сущности 13:02 Механизм адаптеров 13:48 Слой сетей 16:21 Слой виджетов 18:30 Альтернативный подход 20:05 Подводные камни 20:36 Проблемы с кросс-импортом 21:34 Механизм рендер-пропов 22:31 Кросс-импорт сущностей 24:07 Экспериментальная фича 26:00 Проверка корректности импортов 27:05 Кросс-импорт виджетов 29:01 Решение проблемы кросс-импорта 31:55 Проблемы и решения в подслоях 32:28 Итоги и методология FSD 33:26 Когда использовать FSD 35:24 Вопросы и ответы 37:57 Интеграция с редакторами 39:26 Автоматизация и линтеры 40:58 Погружение новичков в методологию 42:14 Вопросы по реализации и дженерикам 43:14 Использование FSD для админок 43:51 Совместимость FSD с фреймворками 44:51 Заключение и вопросы из чата

@gyros9162 6 ай бұрын

Александр классный докладчик! Просмотрел до конца. Но мне до сих пор не понятно, какие проблемы решает FSD на фронте, что делает проще, легче и быстрей. Ощущение, что этот FSD ради FSD и при этом довольно трудно ему следовать ибо концепция довольно субъективна

@Wystov 5 ай бұрын

Судя по видео, FSD не решает проблемы, а создает их. И докладчик 45 минут объясняет нам, как продолжать ехать на велосипеде после того, как мы сами себе вставили палку в колесо.

@lolhohol 5 ай бұрын

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

@lolhohol 5 ай бұрын

@@xxxxxxxeeeeeeeeee ну получается это проблема человека который понял тогда, методология то тут причем?) Но я и не спорю, что это какая то серебряная пуля, совсем нет. Мне наоборот проще по старинке работать, и гемороя меньше.

@gh8499 4 ай бұрын

@@lolhohol возьмите готовое блюдо, выбросите его и съешьте говно и все вопросы будут закрыты. Я раньше тоже думал надо ли оно мне. Оказалось что надо.

@lolhohol 4 ай бұрын

@@gh8499ничего не понятно, но очень интересно

@alexanderzelenkov6944 4 ай бұрын

Кстати, неплохой доклад. Я думал он, как адепт ФСД, будет рассказывать как ОЧЕНЬ важно все раскладывать по нужным папочкам, а он практически сразу сказал про то что, ну вот не работает на больших проектах. Свой линтер и настойчивость команды ФСД в упоре на "чистый" ФСД - это не очень хороший сигнал. Вообще, конечно, хорошая идея держать структуру папочек максимально плоской и иметь хоть какую-то конвенцию по их неймингу. Но по мне так ФСД - это чисто русскоязычная тема, за которой не стоит какой-то реальной технологии, а конвенцию папочек я и сам вам придумаю или пойму (если ее писали с капелькой здравого смысла). Я бы не хотел работать в команде с жесткими адептами ФСД.

@livechat1608 6 ай бұрын

Че за эпилепсия у монтажера. Докладчик рассказывает новые штуки опираясь на слайд, нам покажут зал, покажут докладчика, покажут взгляд под углом, но не сам слайд 🤦‍♀️ Некоторые слайды в кадре появляются буквально на 2 секунды, даже прочитать не успеваешь как уже меняются. И это опять же гениальное чувство монтажника.

@RomanTchekashov 6 ай бұрын

Что плохого в модульной архитектуре на подобии той, что используется в Ангуляр проектах? FSD по сравнению с ней гораздо сложнее;( В одной крупной компании придумали, все копируют, совершают ошибки, сам FSD частенько конфликтует с другими библиотеками и фреймворками, при чем даже с документацией в ней сложно разобраться и по итогу проект только еще сложнее становится.

@valikirr 6 ай бұрын

тем что даже в ангуляре в модульной архитектуре можно довольно хорошо поговнокодить. fsd ложится хорошо под любую архитектуру будь то react, angular или vue, и вообще никак не конфликтует. В ангуляре не используя никакой методологии, можно наклепать модулей, и все равно иметь зависимости между модулями, потому что некоторые вещи с ростом проекта, как правило, начинают использоваться в нескольких модулях. можно вынести все в shared, тогда будет у тебя вроде как переиспользуемый код с одной стороны, а с другой стороны у этот код будет содержать бизнес логику, а так как еще он используется в разных модулях, наверняка он еще будет меняться под новые какие то требования, а это уже нарушает обычный SOLID. методология FSD совершенствуется, потому что общество растет, вопросов становится больше, и следовательно и ответов на эти вопросы. FSD требует не документацию, а целую книгу, потому что это архитектурная методология. Строгих инструкций тут быть не может. Ты также не найдешь документацию по DDD, нужно прочитать как минимум одну книгу, и поработать с каким то проектом, чтобы понять что да как.

@SuhushinAS 6 ай бұрын

Наговнокодить можно где угодно, и fsd тут не исключение.) А "кривой" концепт fsd, который сами авторы не могут описать в документации, не слабо увеличивают эту вероятность.)

@valikirr 6 ай бұрын

@@SuhushinAS есть телега, есть сообщество, есть бот который поможет ответить на многие вопросы, есть множество примеров... остальное уже в ответственности разраба

@SuhushinAS 5 ай бұрын

@@valikirr В ответственности разработчика - выбрать архитектуру, которая понятна, без сидения в чатах и имеет все те же преимущества)

@valikirr 5 ай бұрын

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

@NikVolkov 5 ай бұрын

Прекрасный доклад

@novailoveyou 11 күн бұрын

28:06 что это? Это не скомпелируется

@menelaus365 Күн бұрын

Скомпилируется

@novailoveyou Күн бұрын

@menelaus365 ну попробуй)

@menelaus365 Күн бұрын

@@novailoveyou А в чём проблема? Там map в листе будет передавать статью в эту функцию, и jsx рендерить

@EwKlidstudio 3 ай бұрын

Я пытаюсь внедрить FSD на всех своих проектах уже как год, но сейчас понимаю, что это оверрейтед методология) Даже в самых базовых случаях приходится нарушать привила (например кросс-импорты). Надо придумывать что-то другое

@MrJloa 25 күн бұрын

Это когда фича1 хочет что-то фичи2?

@developerdiary3136 6 ай бұрын

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

@adamburke4496 Ай бұрын

А как это относится к теме доклада? Каждый уже сам решает, как он будет этим модельки создавать.

@fiatluxinregnonoctis 6 ай бұрын

Мандец, этот FSD такой запутанный))

@ddflruc 6 ай бұрын

На мой взгляд, бесполезный доклад, продающий бесполезную FSD-методологию, которая только в теории звучит хорошо, а на практике создает только проблемы с неудобным "размазыванием" кодовой базы по многим файлам, созданием излишних сущностей, папок, файлов и смысловых противоречий даже в простом проекте. Кому FSD упростил жизнь в боевом проекте? Напишите, пожалуйста, ответ на этот комментарий. Я пробовал FSD и ужаснулся от его бесполезности для решения реальных проблем сложности разработки любых frontend-проектов.

@vgsnva 6 ай бұрын

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

@BorisEdigarian 5 ай бұрын

Какая архитектура тогда полезна ? FSD не заставляет вас создавать сущности, по сути только 3 слоя обязательны(app, pages, shared), можно все делать в папке pages, и выносить общие компоненты в shared.

@ddflruc 5 ай бұрын

@@BorisEdigarian Любая кастомная модульная архитектура, удобная команде или группе команд. По моему, это очевидно, разве нет? Если, как вы сказали "можно все делать в папке pages, и выносить общие компоненты в shared.", то где тут FSD, подразумевающий наличие Entities, Features и прочие излишние абстракции? В вашем описании не прослеживается какая-либо архитектурная методология, а я спросил про то, кому FSD упростил жизнь в РЕАЛЬНОМ ПРОДЕ.

@alexandrcorbin Ай бұрын

@@BorisEdigarian app, pages, shared - друг, то что ты описал понимает любой неглупый разработчик на фронте и без FSD коршунов. app, pages, shared - это та база, с которой я уже ни один проект начинал. При чём тут fsd вообще?

@jackdoe1312 2 ай бұрын

Очень слабо, по сравнению с курсом по FSD от Евгения Паромова. Александр, как будто заучил по бумажке перед выступлением. У Ильи же сразу видно - человек сам лично прошел через проблемы по построению архитектуры на фронтенде, где в своём видео всесторонне объясняет тематику.

@iGotton 4 ай бұрын

@paulmalys Ай бұрын

FSD модная, но максимально бездарная архитектура. Не используйте ее.

@alekssjeva951 Ай бұрын

Уви-юви-юви-юви-ю, оу, уви-юви-юви-юви-ю, оу🤣🤣🤣 Впечатление, что во врот-энде количество мудацких, бессмысленных фич просто запредельное. Сначала пришли фреймворки, потом - фреймворки под фреймворки, бесчисленное количество надстроек над ними. И вот снова какое-то очередное унылое смузихлёбство. Как же хорошо, что пишу на чистой ванили и php, и не надо париться над этой всей дичью.

@alexandrcorbin Ай бұрын

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