Посмотрел до середины, ролик просто пушка, как ты и сказал это самый полный ролик и понятный по архитектуре из всех что я находил. Думаю народ не даст соврать, что на ютубе в основном конференции всякие с кучей воды, а тут все коротко, по существу, еще и с графикой. Ты задаешь планку качества, от меня тебе благодарность
Первое впечатление от FSD - катострофическая сложность, которая непременно приведет к свалке, ведь подобный абстрактный ряд правил все будут интерпретировать по-своему. Только в отличие от [No Architecture] свалка будет не плоской, одноуровневой, а ультравложенной и иерархической - т.е. мегасвалкой.
Очень хороший контент. Автор вообще всегда доступно и без воды доносит саму суть. Относительно этой темы. Сам я уже не первый год работаю и несколько неправильно набирался опыта - все архитектурные решения, реализации многих вещей делал, не ознакамливаясь с существующими практиками и готовыми решениями. И лично я отталкивался от такого можно сказать "математического" подхода: то, что повторяется - "за скобки". В итоге пришёл примерно к тому, в чём заключается FSD. Конечно же, каждый раз с учётом индивидуальных особенностей отдельного проекта. На практике в результате это, как минимум, может в разы увеличить скорость разработки проекта, что на длительной дистанции даёт огромный выхлоп. А так в целом озвученные подходы - это разными словами и в разной степени сложности об одном и том же) Если у вас всё хорошо с логикой да и вообще вы по жизни педант и перфекционист, достаточно будет один раз услышать всё это, "чтобы быть в курсе", а к идеальной архитектуре придёте и сами. Миксуя существующие подходы и добавляя что-то от себя.
@@27sosite73 хотя я читал статью, и там такая проблема решается тем, что на каждый микросервис конкретные люди от начала его создания и до самого вывода мс из эксплуатации. технически, это позволить хотя бы как-то не разводить бардак и это действительно дельный совет, но дорогой, типа держать команду целую либо если на одну какую-то команду возложить несколько мс. Но есть риск в степени К если команда свалит или распадется, тогда труба всем этим мс, ибо новые спецы каждый же по своему смотрит, со своей колокольни. короче все это пиз.. как 😋весело
все сложное начинается с чего-то простого. По крайней мере так должно быть. Если разработчик не в состоянии декомпозировать задачи, то ему ни один паттерн, не поможет
В чем смысл хейтить такой контент? Ну допустим автор где то ошибся, но как минимум 90% инфы то правильная, а ошибку по ходу изучения других курсов (или прочесть комментарий с примечанием) можно и самому потом найти и исправить. Благо, есть много курсов на русском/английском.
О, как же я долго ждал такое видео! Спасибо тебе большое!!! Огонь! Долго присматриваюсь к FSD но понять ее было не просто. Сейчас стало более понятно и в теории, и на практике!
Feature sliced design это лишь один из вариантов реализации clean arhitecture дядюшки Боба. В целом считаю, что данные ролик подойдет только для понимания что архитектура приложения есть, и что хорошо бы про это почитать, но никак не для практического применения. Очень сильная завязка на структуре проекта, как по папочкам все разложить, а это совсем не тоже самое что архитектура.
Очень ждал это видео, с самого момента твоего анонса роликов по архитектуре. Ты делаешь вещи, определенно. После просмотра отпишу про материал Спасибо.
Однонаправленная (и только вверх) и явная благодарность тебе, Тимур! Ролик не остался незмеченным и невкатанным в голову из-за прочно понятной логической структуры контента. Чисто субъективно хочу выделить, что моим мозгам особенно приятно, когда ты грамотно раскидываешь такие архитектурные скелеты не только в схемы, но и в папки и файлы в проекте. И годными примерами ещё подкрепляешь, что и порождает наслойку знания. И как незаменимый бонус, способ мышления также переходит в новые рельсы, которые одерживавют верх над старыми привычками. Спасибо, что почти каждый ролик ты пропитываешь такой идеей, что как нет волшебной таблетки, так нет и чудо - архитектуры. ) Только не надо надеяться, что вот-вот и мы уж точно наверняка все поймём, всю универсальность. Ничего неправда) так как по мере расширения нашего знания, расширяется наше и незнание. Площадь соприкосновения с ним становится больше. Но в этом и есть азарт) Необходимо думать и быть начеку, и если может сразу не всегда получается, то не забывать опираться на ООП китов 😉) (единственное, но опять же вкусовщина, я бы сделала шрифт потоньше для читабельности лёгкой или у меня уже просто глаза плывут, но такой контент не досмотреть до конца на одном дыхании просто невозможно 🤍)
по всему видео при определении свойств архитектуры идет упоминание, что поток данных у нас однонаправленный вот как тут 31:40, (это же было и про модульную) не вижу просто ни потока, ни данных, по мне, некорректно так говорить, потому что первое, что приходит в голову это "props drilling" еще это обычно использовалось в контексте описания самой архитектуры будь то реакта или его сторов. правильнее в данном контексте было бы сказать иерархия управления или иерархия зависимостей или иерарахическая композиция зависимостей. спасибо, было интересно глянуть!!!
Думаю, очень важно внимательно посмотреть тем, кто собирается или начинает свой первый проект(-ы), а то частенько бывает так, что стартуешь проект и не понимаешь с чего начать. Это может выбить из колеи, а архитектура убирает вопрос на корню. В любом случае, приятного просмотра всем
В документации React советуют не тратить больше 5 минут на выбор структуры проекта. Практичнее пересматривать ее по мере развития проекта. Но когда в начале уже есть готовая архитектура, то это конечно плюс
@@ЕвгенийПалыч-ю4и пилить "свалку компонентов" и позволить им учиться на своих же ошибках. Джуны в FSD все равно не смогут, равно как и написать большое приложение. Когда подберут определенное количество опыта, тогда и пересмотрите архитектуру в соответствии с уже изученными бизнесовыми требованиями.
Ты очень сэкономил мне время! Спасибо за структурированную работу. Усвоил конечно не все, нужна практика) - Понравилась идея линтинга для запрета импорта кишков модуля. - Понравилась ремарка о том, с какими проблемами столкнемся, если не будем использовать монорепозиторий. - Понравилось наглядное сравнение Модульной и Atomic архитектур с проведением линий на 26:15. Думаю, сильно улучшило бы понимание такое же сравнение Модульной и Feature-sliced архитектур. - Увидел, как Feature-sliced решает проблему использования "модуль в модуле" за счет увеличения количества слоев. Но у меня остался вопрос, как в Feature-sliced решается 4-й недостаток Модульной архитектуры (21:53)? Было сказано, что глобальные сторы/хэлперы могут создавать неявные связи между собой, но как от этой проблемы избавиться в Feature-sliced, пока непонятно, там ведь тоже придется куда-то класть глобальный стор. Был бы очень кстати конкретный пример такой проблемы и ее решения.
@@DENisHolden1 о. У меня такой же вопрос) А если стор не общий, например, на Effector'е, тогда 4 недостаток пропадает и у модульной архитектуры, и у FSD?
@@DENisHolden1 а какая связность в этих подходах от общего стора? Не совсем тут понимаю. Мы же создаем стор на самой верхушке этого однонаправленного потока, оборачиваем в этот провайдер все приложение, все редьюсеры вытаскиваем из модулей, с самого верхнего уровня это разрешается делать.
У тебя дар раскладывать информацию по полочкам! Я именно после этого видоса понял FSD достаточно хорошо. Именно после этого ролика все встало на свои места! Спасибо большое за твою работу!
11:29 UI 11:48 компоненты 12:40 модули 14:11 15:00 16:01 хелперы 16:14 store 16:43 изоляция модулей с помощью public api 18:00 ограничение внутренностей модуля с помощью линтера 18:05 подитоживание 18:55 страницы 19:43 поток однонаправленный 20:46 преимущества перед классическим подходом 21:17 недостатки подхода 22:07 22:47 сравнительный анализ 23:53 Atomic design методология. Слои: Атомы (UI-слой) 25:11 Молекулы 25:26 Организмы 25:38 Шаблоны 25:51 Страницы 26:08 Аналогия с модульной архитектурой 26:36 Преимущества/недостатки 26:57 Feature sliced design (модульная на стероидах) 27:58 Слои .... 29:20 features 29:51 widgets 30:42 Сегменты 31:58 Ещё раз про слои ... 33:29 processes 33:58 app 34:28 35:10 Сравнение с тремя принципами ООП. Реализация структуры Ideal (в правом нижнем углу) с помощью данной методологии: 37:24 за счёт чего достигается слабое зацепление между модулями 40:13 за счёт чего достигается связанность внутри модулей 41:05 ещё раз про слои. Более детальные примеры каждого слоя: 42:51 слой shared 44:1245:22 слой enteties (с этого момента еще раз пересмотреть) 47:37 слой features 48:20 слой widgets 49:10 слой pages 49:44 слой app 50:08 итог 51:30 преимущества FSD 53:40 недостатки FSD 54:27 снова упоминание важности использования линтероа для ограничения доступа разработчикам к другим слоям, которыми они не занимаются. 55:22 сравнение FSD с простой модульной архитектурой 55:55 Микрофронтенд + монорепа + модульная
FSD сначала показался похожим на Domain Driven Design (DDD). Но имеет большие отличия: DDD максимально оторван от UI и фреймворка (в FSD визуальные компоненты живут в каждом "слое"). В DDD можно писать на классах c DI со всеми ООП принципами. А можно и в функциональном стиле. Плюсом FSD отмечу стандартизацию и документацию, это популяризирует его. Хороший материал, был интересно узнать про FSD.
Спасибо! Наконец-то получилось разобраться с FSD. Хоть кто-то объяснил без воды, на реальном примере. Мне сеньор скинул официальную документацию и это видео в качестве материалов для изучения) Видео прояснило все гораздо больше, нежели документация. Пошла переделывать проект🥲🙂
15:35. Апи это зависимость на внешнюю систему. И одно апи может потребоваться в разных модулях. Так что такая красивая схема только на рисунке будет. Мне кажется лучше апи выносить отдельно
Видео просто замечательное. Но в идеале было бы сделать видео по том как ты делаешь какой-нибудь простецкий проект по Feature sliced design так как, без каких-то явных примеров на практике довольно сложно понять в каком случае по каких папкам все разносить.
Спасибо за видео. И всё в итоге сводиться к общепринятой культуре которая уже установилась в коллективе. А потом, каждый начинает доказывать, что модуль или компонент должен лежать там или там-то, потом приходит тимлид и отдает преймущество тому методу с каким программистом он больше дружит, а на место того програмиста чей вариант не прошел назначаеться следующий кандидит. ... круговорот програмистов в Web-е.
Я пока учусь, но уже встретился с учебным проектом с классической безархитектурой и этим бардаком. Автор прям перечислил все мои боли. Как же я щас кайфанул, когда узнал про модульную и другие архитектуры! Вообще дьявольски хороший ролик, просто мастхэв.
Спасибо за ролик! Применяю на работе FSD над новым проектом. Намного лучше, чем свалка. Но, нужно перенастроить мозг - привыкнуть. Очень хорошо помогает раздербанить на слои, дизайнерский макет в Фигме.
Идея для ролика! Современная архитектура приложения - как развервнуть локально приложение, например в docker, можно выбрать какой-нибудь стек.. для меня лично - очень интересно послушать, что думают/умеют другие команды!
Спасибо за обзор! )) Всю дорогу не покидает чувство какого-то сплошного противоречия от Feature Sliced. - "Чем ниже слой, тем легче что-то сломать" - сомнительный комментарий в сторону такой архитектуры. - Когда любой верхний слой может использовать любой нижний в любом порядке и количестве - это не приводит к клубкам неявных связей? Что-то не доходит, например, как в подходе Feature Sliced предлагается решать такой случай: - есть две формы: форма А создаёт в системе объект данных с типом А1, форма Б - объект данных с типом Б1 - в форме А есть специальное поле с кнопкой, по нажатию на которую должна открываться форма Б в модальном окне - пользователь создаст в этом окне создаст новый объект типа Б1, модалка скроется и в поле рядом с кнопкой должно отобразиться название только что созданного объекта - дальше работа с формой А продолжится в штатном режиме Ответ в стиле "пересмотреть пользовательский путь" и "вырожденный пример" можно трактовать не пользу архитектуры, т.к. этот самый путь продиктован требованиями к реализации со стороны бизнеса на одном из прошлых проектов. ;)
- "Чем ниже слой, тем легче что-то сломать" - сомнительный комментарий в сторону такой архитектуры. Когда много клиентов у какого-то слоя, то это отразиться на работе клиентов. Соответственно, самое большое количество клиентов у самого нижнего слоя, не заметил ничего сомнительного - Когда любой верхний слой может использовать любой нижний в любом порядке и количестве - это не приводит к клубкам неявных связей? Что-то не припомню, чтобы было сказано именно об использовании любого нижнего слоя в любом порядке. Слои идут друг за другом и использовать их нужно тоже друг за другом, никаких любых нижних слоев, только нижестоящий. Мы же не можем выйти из квартиры на улицу минуя лестничную клетку или лифт.
Не престаю восхищаться талантом Тимура. Каждый видос это сотни часов моего времени, которое ты спас дорогой друг. Чувствуется что ты тратишь много времени. Но в подумай сколько времени ты нам экономишь в сумме) тысячи лет . Тимур. А можешь сделать видео о безопасности в контексте архитектуры желательно Full Steck приложение как фундамент для огромного проекта. И рассказать где можно сделать неправильно и ослабить безопасность в проекте. Спасибо 😊
по FSD недостатки описаны в формате: слишком хорош, слишком масштабируем, слишком много порядка в нём 🤣 А вот, лично я заметила вот такие недостатки: 1. субъективность разбиения. Часто не понятно ни как сущность назвать, ни к какому слою её отнести. Это провоцирует конфликты. 2. целостность восприятия кода, его цели и задачи размыты. Анализ кода усложняется, контроль за тем что где хранится -тоже
Скорее всего тебе уже говорили, но многие твои видео действительно очень информативные и полезные, а изложение материала - последовательное и максимально понятное. Такие видео выгодно отличаются, даже если их сравнивать с некоторыми онлайн-курсами
Лучший! Очень долго искал толковую информацию об архитектуре, но никак не мог её найти, и тут выходит твой ролик, и всё сразу доходчиво и понятно объяснил что да как. Спасибо большое
это лучший канал по программированию , посмотрел много уроков на разных этаппах своей жизни . Программировал на с++ видео очень помогали сейчас пишу на react нужда этого канала не пропала .Спасибо большое за отличные уроки
Боже, ты настолько крут, спасибо тебе! Я благодаря твоим видосам про реакт и vue начал писать на этих фреймворках, а теперь начну писать на них правильно! Чую на курс к тебе пора. Может будет запись курса что бы можно было купить только видосы?
Спасибо что разложил по полочкам про feature slide design. Видел open sorce проекты с этой архитектурой, но не до конца понимал чем entities от widgets отличается.
Прошла курс полностью, словила ошибку только в этом месте после проверки на неправильный адрес, пришлось закоментить словила ошибку только в этом месте после проверки на неправильный адрес, пришлось закоментить // тайм аут вылетает с ошибкой // setTimeout(() => { dispatch({ type: COMMENTS_LOAD, data: jsonData }); dispatch(loaderOff()); // }, 1000); плюс сейчас новая версия спинера и вот эта конструкция в ней уже не работает import Loader from 'react-loader-spinner'; в остальном все работает, отличный пример спасибо!!!
Новичок, если хочешь сразу нормально - начни с ангуляра. Из коробки порядка больше, чем до середины приемов из этого видео. А feature sliced design - держи в голове, думая куда поместить свою фичу. Реакт с вью, сырая поделка, после нескольких лет работы с ангуляр.
Очень полезное видео. Узнал для себя много нового. Попробую в следующем своем React приложении попробовать архитектуру Feature Sliced Design. Спасибо большое за видео 👍👍👍
Недостатки FSD описывают как раз рецепт того, как нужно подходить к архитектуре проекта при любом подходе. Т.е. если взять любой из сказанных и включить голову, то будет норм. Если взять любой и выключить - будет беда. А так - каждые пол года/год выходят "новые" подходы, хотя как по мне так всё +- одинаковое. Вообще всё оч красиво на бумаге) На деле, когда проходит 3-4 года и кучу рефакторингов, картина может быть очень печальна.
Странно выглядит зачёркивание красным что "мы рассмотрели". Как будто это плохо, мы это вычёркиваем и начинаем разбирать как правильно. Но в конце у нас всё зачёркнуто красным 😁(как в туду проектах, но там про другое). По моему, отмечать галочкой намного удобнее для восприятия. Можно цветными галочками для расстановки акцентов над вариантами решений.
фигачу стартап на архитектуре "без архитектуры" все довольны, все работает ))) через 5 лет спросите чем все закончилось :D имхо считаю что простая-модульная архитектура вполне себе отлично подходит для небольших проектов с масштабом регионального уровня, и то, только в критически важных местах, по типу авторизации или управления правами доступа и только исходя из этических соображений (по факту эти модули можно вообще отдельно вынести на уровень самостоятельных апк и гонять основу на токенах). В общем мне кажется здесь больше смысл не в том какая у вас архитектура, а как вы провели декомпозицию, в следствии чего получили желаемый, заветный уровень абстрагирования, т.е. имхо независимости.. ну да, это можно назвать архитектурой, но я как-то подсознательно не хочу это делать.. поскольку видимо все течет и меняется во времени, и не применимо к концепции архитектур в принципе. или может просто я не готов к тому, что все более новые и новые архитектуры так быстро появляются :D ..а это уже предмет для философских размышлений. В любом случае здесь решает мнение на основе опыта TL и PM.
Ещё полгода назад я впервые посмотрел ролик по реакту у тебя, а теперь ебашу мобильную приложуху с килотонным, для меня, стеком и кайфую. Спасибо тебе! Очень нравятся собесы
Привет хотелось бы уточнить на счет FSD. В примере с entities/user ты показывал папку api, в которой были createUser, updateUser запросы. У меня вопрос почему такие вещи касаются самой entity, а не какой-то фичи из слоя feature или widget по типу createUserForm, updateUserForm?
Крутейший материал, спасибо огромное! Было бы невероятно круто в дополнение прикладывать ссылки на хорошие примеры проектов или реализовать некий тестовый проект на предложенных архитектурах. Можно потратить очень много лет, чтобы дойти до этого всего. Просто завидую тем, кто сейчас может это все получить в готовом виде, да еще и таким простым языком. )
Спасибо автору, смог по новому взглянуть на сферу в которую относительно недавно залетел. Здорово, что можно применить FSD в no-code разработке, может немного не в том виде как в классическом программировании, но всё же))
Видос отличный, большое спасибо за огромный пласт информации. Единственное замечание, что последняя архитектура - это скорее не микросервисный подход, а разделение кода на библиотеки. А так прям круто!
Тимур, улбик реально спасибо большое тебе, очень сильно помогаешь. Уверен, что без твоего контента я бы потратил больше времени на обучение. Продолжай в том же духе!
Посмотрел до середины, ролик просто пушка, как ты и сказал это самый полный ролик и понятный по архитектуре из всех что я находил. Думаю народ не даст соврать, что на ютубе в основном конференции всякие с кучей воды, а тут все коротко, по существу, еще и с графикой. Ты задаешь планку качества, от меня тебе благодарность
Первое впечатление от FSD - катострофическая сложность, которая непременно приведет к свалке, ведь подобный абстрактный ряд правил все будут интерпретировать по-своему. Только в отличие от [No Architecture] свалка будет не плоской, одноуровневой, а ультравложенной и иерархической - т.е. мегасвалкой.
Такая чистая речь, после прослушивания конференций всяких, это так удивительно слушать 😮
Очень важный и крутой ролик. ОГРОМНОЕ тебе спасибо за развитие frontend разработки в русскоязычном пространстве
Очень хороший контент. Автор вообще всегда доступно и без воды доносит саму суть.
Относительно этой темы. Сам я уже не первый год работаю и несколько неправильно набирался опыта - все архитектурные решения, реализации многих вещей делал, не ознакамливаясь с существующими практиками и готовыми решениями. И лично я отталкивался от такого можно сказать "математического" подхода: то, что повторяется - "за скобки". В итоге пришёл примерно к тому, в чём заключается FSD. Конечно же, каждый раз с учётом индивидуальных особенностей отдельного проекта. На практике в результате это, как минимум, может в разы увеличить скорость разработки проекта, что на длительной дистанции даёт огромный выхлоп.
А так в целом озвученные подходы - это разными словами и в разной степени сложности об одном и том же) Если у вас всё хорошо с логикой да и вообще вы по жизни педант и перфекционист, достаточно будет один раз услышать всё это, "чтобы быть в курсе", а к идеальной архитектуре придёте и сами. Миксуя существующие подходы и добавляя что-то от себя.
это всё на бумаге красиво звучит, как только начинается сложный проект то такие архитектуры сложно реализовать
челоресур ротируется, все превращается в кашу в любом случае
@@KGB1st da =(
@@27sosite73 хотя я читал статью, и там такая проблема решается тем, что на каждый микросервис конкретные люди от начала его создания и до самого вывода мс из эксплуатации. технически, это позволить хотя бы как-то не разводить бардак и это действительно дельный совет, но дорогой, типа держать команду целую либо если на одну какую-то команду возложить несколько мс. Но есть риск в степени К если команда свалит или распадется, тогда труба всем этим мс, ибо новые спецы каждый же по своему смотрит, со своей колокольни. короче все это пиз.. как 😋весело
все сложное начинается с чего-то простого. По крайней мере так должно быть. Если разработчик не в состоянии декомпозировать задачи, то ему ни один паттерн, не поможет
Автор этим видео вырывается на топ уровень авторов годного материала, полезность зашкаливает.
У него курс выходит, а он полезный видос на час выпускает. Что с лицом хейтеры? Ещё раз увижу, сразу в бан улетите 😈
:D
:)
В чем смысл хейтить такой контент? Ну допустим автор где то ошибся, но как минимум 90% инфы то правильная, а ошибку по ходу изучения других курсов (или прочесть комментарий с примечанием) можно и самому потом найти и исправить. Благо, есть много курсов на русском/английском.
Не перни
О, как же я долго ждал такое видео! Спасибо тебе большое!!! Огонь! Долго присматриваюсь к FSD но понять ее было не просто. Сейчас стало более понятно и в теории, и на практике!
Feature sliced design это лишь один из вариантов реализации clean arhitecture дядюшки Боба. В целом считаю, что данные ролик подойдет только для понимания что архитектура приложения есть, и что хорошо бы про это почитать, но никак не для практического применения. Очень сильная завязка на структуре проекта, как по папочкам все разложить, а это совсем не тоже самое что архитектура.
Критикуешь - предлагай
Ещё бы узнать где почитать
Очень ждал это видео, с самого момента твоего анонса роликов по архитектуре. Ты делаешь вещи, определенно. После просмотра отпишу про материал
Спасибо.
Комментарий в поддержку канала! Тимур, ты супер!
Буквально за 3 минуты (27:45 - 31:25) автор объяснил суть FSD, который вызывает у меня боль на проекте) Спасибо)
Спасибо за такой качественный контент, который оч трудно найти на просторах интернета
Однонаправленная (и только вверх) и явная благодарность тебе, Тимур! Ролик не остался незмеченным и невкатанным в голову из-за прочно понятной логической структуры контента.
Чисто субъективно хочу выделить, что моим мозгам особенно приятно, когда ты грамотно раскидываешь такие архитектурные скелеты не только в схемы, но и в папки и файлы в проекте. И годными примерами ещё подкрепляешь, что и порождает наслойку знания.
И как незаменимый бонус, способ мышления также переходит в новые рельсы, которые одерживавют верх над старыми привычками.
Спасибо, что почти каждый ролик ты пропитываешь такой идеей, что как нет волшебной таблетки, так нет и чудо - архитектуры. )
Только не надо надеяться, что вот-вот и мы уж точно наверняка все поймём, всю универсальность. Ничего неправда) так как по мере расширения нашего знания, расширяется наше и незнание. Площадь соприкосновения с ним становится больше. Но в этом и есть азарт)
Необходимо думать и быть начеку, и если может сразу не всегда получается, то не забывать опираться на ООП китов 😉)
(единственное, но опять же вкусовщина, я бы сделала шрифт потоньше для читабельности лёгкой или у меня уже просто глаза плывут, но такой контент не досмотреть до конца на одном дыхании просто невозможно 🤍)
Спасибо за такое бесплатное распространение столь важной инфы! Очень полезно!
по всему видео при определении свойств архитектуры идет упоминание, что поток данных у нас однонаправленный вот как тут 31:40, (это же было и про модульную)
не вижу просто ни потока, ни данных, по мне, некорректно так говорить, потому что первое, что приходит в голову это "props drilling"
еще это обычно использовалось в контексте описания самой архитектуры будь то реакта или его сторов.
правильнее в данном контексте было бы сказать иерархия управления или иерархия зависимостей или иерарахическая композиция зависимостей.
спасибо, было интересно глянуть!!!
Думаю, очень важно внимательно посмотреть тем, кто собирается или начинает свой первый проект(-ы), а то частенько бывает так, что стартуешь проект и не понимаешь с чего начать. Это может выбить из колеи, а архитектура убирает вопрос на корню. В любом случае, приятного просмотра всем
В документации React советуют не тратить больше 5 минут на выбор структуры проекта. Практичнее пересматривать ее по мере развития проекта. Но когда в начале уже есть готовая архитектура, то это конечно плюс
@@notrodans да? А когда у тебя команда из 5 джунов, которым нужно сделать большое приложение? Всем ждать пока синъерами станут?
@@ЕвгенийПалыч-ю4и Уволить 5 джунов, взять 1 синьера, очевидно же))
@@ЕвгенийПалыч-ю4и пилить "свалку компонентов" и позволить им учиться на своих же ошибках. Джуны в FSD все равно не смогут, равно как и написать большое приложение. Когда подберут определенное количество опыта, тогда и пересмотрите архитектуру в соответствии с уже изученными бизнесовыми требованиями.
Выход нового ролика это целый праздник! 😍 спасибо, Тимур!
Как же вовремя, только с твоих видосов по разборам проектов, где ты поправлял чужой код. Как раз возникло желание углубиться в архитектурный аспект
Ты очень сэкономил мне время! Спасибо за структурированную работу. Усвоил конечно не все, нужна практика)
- Понравилась идея линтинга для запрета импорта кишков модуля.
- Понравилась ремарка о том, с какими проблемами столкнемся, если не будем использовать монорепозиторий.
- Понравилось наглядное сравнение Модульной и Atomic архитектур с проведением линий на 26:15. Думаю, сильно улучшило бы понимание такое же сравнение Модульной и Feature-sliced архитектур.
- Увидел, как Feature-sliced решает проблему использования "модуль в модуле" за счет увеличения количества слоев.
Но у меня остался вопрос, как в Feature-sliced решается 4-й недостаток Модульной архитектуры (21:53)? Было сказано, что глобальные сторы/хэлперы могут создавать неявные связи между собой, но как от этой проблемы избавиться в Feature-sliced, пока непонятно, там ведь тоже придется куда-то класть глобальный стор. Был бы очень кстати конкретный пример такой проблемы и ее решения.
Если стор один общий для всех, то никак от связности не избавиться. Так что 4 недостаток сохраняется
@@DENisHolden1 о. У меня такой же вопрос)
А если стор не общий, например, на Effector'е, тогда 4 недостаток пропадает и у модульной архитектуры, и у FSD?
@@DENisHolden1 а какая связность в этих подходах от общего стора? Не совсем тут понимаю. Мы же создаем стор на самой верхушке этого однонаправленного потока, оборачиваем в этот провайдер все приложение, все редьюсеры вытаскиваем из модулей, с самого верхнего уровня это разрешается делать.
У тебя дар раскладывать информацию по полочкам! Я именно после этого видоса понял FSD достаточно хорошо. Именно после этого ролика все встало на свои места! Спасибо большое за твою работу!
11:29 UI
11:48 компоненты
12:40 модули
14:11
15:00
16:01 хелперы
16:14 store
16:43 изоляция модулей с помощью public api
18:00 ограничение внутренностей модуля с помощью линтера
18:05 подитоживание
18:55 страницы
19:43 поток однонаправленный
20:46 преимущества перед классическим подходом
21:17 недостатки подхода
22:07
22:47 сравнительный анализ
23:53 Atomic design методология. Слои:
Атомы (UI-слой)
25:11 Молекулы
25:26 Организмы
25:38 Шаблоны
25:51 Страницы
26:08 Аналогия с модульной архитектурой
26:36 Преимущества/недостатки
26:57 Feature sliced design (модульная на стероидах)
27:58 Слои
....
29:20 features
29:51 widgets
30:42 Сегменты
31:58 Ещё раз про слои
...
33:29 processes
33:58 app
34:28
35:10 Сравнение с тремя принципами ООП.
Реализация структуры Ideal (в правом нижнем углу) с помощью данной методологии:
37:24 за счёт чего достигается слабое зацепление между модулями
40:13 за счёт чего достигается связанность внутри модулей
41:05 ещё раз про слои. Более детальные примеры каждого слоя:
42:51 слой shared
44:12 45:22 слой enteties (с этого момента еще раз пересмотреть)
47:37 слой features
48:20 слой widgets
49:10 слой pages
49:44 слой app
50:08 итог
51:30 преимущества FSD
53:40 недостатки FSD
54:27 снова упоминание важности использования линтероа для ограничения доступа разработчикам к другим слоям, которыми они не занимаются.
55:22 сравнение FSD с простой модульной архитектурой
55:55 Микрофронтенд + монорепа + модульная
Спасибо за проделанную работу, получилось отличное видео. Всем приятного просмотра
Спасибо за материал!
Взял курс, очень жду начала)
FSD сначала показался похожим на Domain Driven Design (DDD). Но имеет большие отличия: DDD максимально оторван от UI и фреймворка (в FSD визуальные компоненты живут в каждом "слое"). В DDD можно писать на классах c DI со всеми ООП принципами. А можно и в функциональном стиле. Плюсом FSD отмечу стандартизацию и документацию, это популяризирует его. Хороший материал, был интересно узнать про FSD.
Спасибо! Наконец-то получилось разобраться с FSD. Хоть кто-то объяснил без воды, на реальном примере. Мне сеньор скинул официальную документацию и это видео в качестве материалов для изучения) Видео прояснило все гораздо больше, нежели документация. Пошла переделывать проект🥲🙂
Твои видосы это просто лучшее что можно найти на русском ютубе, мега полезно
Спасибо за отличный материал
Огромное спасибо за архиролик! Архитектура стоит над технологиями и фреймворками. Перевожу свой рабочий проэкт на FSD.
15:35. Апи это зависимость на внешнюю систему. И одно апи может потребоваться в разных модулях. Так что такая красивая схема только на рисунке будет. Мне кажется лучше апи выносить отдельно
Большое спасибо вам за такой подробный ролик. Не первый год работаю программистом, но всё равно очень много полезного для себя подчеркнул
Ну вот в упор не понимаю разницы между entities и features, смотрю примеры в доках и кто куда горазд.
Так не хватало понимания архитектуры на фронте. Спасибо за то, что ты делаешь!
смерть узким ублюдкам
Видео просто замечательное. Но в идеале было бы сделать видео по том как ты делаешь какой-нибудь простецкий проект по Feature sliced design так как, без каких-то явных примеров на практике довольно сложно понять в каком случае по каких папкам все разносить.
Там документация подробная есть как раз с примерами кода
Спасибо за видео. И всё в итоге сводиться к общепринятой культуре которая уже установилась в коллективе. А потом, каждый начинает доказывать, что модуль или компонент должен лежать там или там-то, потом приходит тимлид и отдает преймущество тому методу с каким программистом он больше дружит, а на место того програмиста чей вариант не прошел назначаеться следующий кандидит. ... круговорот програмистов в Web-е.
Большое спасибо ! Очень полезный видос с визуальной картинкой, иногда не хватает вот таких простых схем !
Turborepo от создателей nextjs в конце забыл упомянуть для монорепы.
Отличное видео, много чего в одном месте собрал!
Очень познавательные ролики, без воды, предметно и по факту.
Один из лучших материалов на канале, must have для каждого фронт разработчика!!
Просто лучший, лучше видео по архитектуре фронта еще не видел
На проекте используем FSD чуть больше года, крутая концепция(иногда не очень ложится на тулкит из за необходимости шаринга между слоями) за видос лайк
Я пока учусь, но уже встретился с учебным проектом с классической безархитектурой и этим бардаком. Автор прям перечислил все мои боли. Как же я щас кайфанул, когда узнал про модульную и другие архитектуры! Вообще дьявольски хороший ролик, просто мастхэв.
Архитектура современных FRONTEND приложений. Спасибо!
Спасибо за ролик!
Применяю на работе FSD над новым проектом.
Намного лучше, чем свалка.
Но, нужно перенастроить мозг - привыкнуть.
Очень хорошо помогает раздербанить на слои, дизайнерский макет в Фигме.
Добрый день. Под свалкой вы имеете ввиду "Классический подход(без архитектуры)" или и "простой модульный" в том числе?
@@_serge_ "Классический подход(без архитектуры)"
Идея для ролика!
Современная архитектура приложения - как развервнуть локально приложение, например в docker, можно выбрать какой-нибудь стек..
для меня лично - очень интересно послушать, что думают/умеют другие команды!
Спасибо за обзор! ))
Всю дорогу не покидает чувство какого-то сплошного противоречия от Feature Sliced.
- "Чем ниже слой, тем легче что-то сломать" - сомнительный комментарий в сторону такой архитектуры.
- Когда любой верхний слой может использовать любой нижний в любом порядке и количестве - это не приводит к клубкам неявных связей?
Что-то не доходит, например, как в подходе Feature Sliced предлагается решать такой случай:
- есть две формы: форма А создаёт в системе объект данных с типом А1, форма Б - объект данных с типом Б1
- в форме А есть специальное поле с кнопкой, по нажатию на которую должна открываться форма Б в модальном окне
- пользователь создаст в этом окне создаст новый объект типа Б1, модалка скроется и в поле рядом с кнопкой должно отобразиться название только что созданного объекта
- дальше работа с формой А продолжится в штатном режиме
Ответ в стиле "пересмотреть пользовательский путь" и "вырожденный пример" можно трактовать не пользу архитектуры, т.к. этот самый путь продиктован требованиями к реализации со стороны бизнеса на одном из прошлых проектов. ;)
- "Чем ниже слой, тем легче что-то сломать" - сомнительный комментарий в сторону такой архитектуры.
Когда много клиентов у какого-то слоя, то это отразиться на работе клиентов. Соответственно, самое большое количество клиентов у самого нижнего слоя, не заметил ничего сомнительного
- Когда любой верхний слой может использовать любой нижний в любом порядке и количестве - это не приводит к клубкам неявных связей?
Что-то не припомню, чтобы было сказано именно об использовании любого нижнего слоя в любом порядке. Слои идут друг за другом и использовать их нужно тоже друг за другом, никаких любых нижних слоев, только нижестоящий. Мы же не можем выйти из квартиры на улицу минуя лестничную клетку или лифт.
@@semensemenov9519 я могу сказать, что пару месяцев спустя переосмыслил взаимодействие слоёв и их элементов. )
Час годноты! Приступаю…
На Jave не тыкаюсь, хорошо поставлена речь, подача инфы супер.
Очень приятно слушать , смотреть.
Дальше твори чудеса 👍👍🤝
Топовая и важная тема !
Спасибо за новые видео по этой теме
Не престаю восхищаться талантом Тимура. Каждый видос это сотни часов моего времени, которое ты спас дорогой друг. Чувствуется что ты тратишь много времени. Но в подумай сколько времени ты нам экономишь в сумме) тысячи лет .
Тимур. А можешь сделать видео о безопасности в контексте архитектуры желательно Full Steck приложение как фундамент для огромного проекта.
И рассказать где можно сделать неправильно и ослабить безопасность в проекте.
Спасибо 😊
Спасибо! Про безопасность давно плейлист хочу записать, руки не доходят
Большое Спасибо очень полезный урок
по FSD недостатки описаны в формате: слишком хорош, слишком масштабируем, слишком много порядка в нём 🤣 А вот, лично я заметила вот такие недостатки:
1. субъективность разбиения. Часто не понятно ни как сущность назвать, ни к какому слою её отнести. Это провоцирует конфликты.
2. целостность восприятия кода, его цели и задачи размыты. Анализ кода усложняется, контроль за тем что где хранится -тоже
Самое лучшее, что я видел. Красава, оч все хорошо разложил по полочкам)
Это очень полезное видео. Благодарю тебя!!!! Ты сделал мою разработку еще проще 👍👍👍
Самый лучший материал на канале Ulbi tv
Скорее всего тебе уже говорили, но многие твои видео действительно очень информативные и полезные, а изложение материала - последовательное и максимально понятное. Такие видео выгодно отличаются, даже если их сравнивать с некоторыми онлайн-курсами
Ты так объясняешь классно, спасибо большое Тимур ! Пришел сюда после доки
Тимурчик, родной, контент в кайф. Выпускай ролики почаще, очень полезный контент, и огромный в клад в обучение. Сасибо!
Блин, вот все прям четенько, лайк, но ох уж этот reduser))
опять же - шикарно 👍👍👍
Какое же шикарное видео, Алби, ты просто красава!
Господи, как это прекрасно. Спасибо большое!
Спасибо, очень качественно, очень доступно. Теперь ролик про солид надо посмотреть.
Как можно быть таким умным? 🤯👏
Обычно не пишу комменты, но тут не удержусь, очень годный контент! То на что Соер потратил годы Ulbi объяснил за 1 час! 😎 Спасибо! 👍
Лучший! Очень долго искал толковую информацию об архитектуре, но никак не мог её найти, и тут выходит твой ролик, и всё сразу доходчиво и понятно объяснил что да как. Спасибо большое
это лучший канал по программированию , посмотрел много уроков на разных этаппах своей жизни .
Программировал на с++ видео очень помогали сейчас пишу на react нужда этого канала не пропала .Спасибо большое за отличные уроки
Боже, ты настолько крут, спасибо тебе!
Я благодаря твоим видосам про реакт и vue начал писать на этих фреймворках, а теперь начну писать на них правильно!
Чую на курс к тебе пора.
Может будет запись курса что бы можно было купить только видосы?
Спасибо что разложил по полочкам про feature slide design. Видел open sorce проекты с этой архитектурой, но не до конца понимал чем entities от widgets отличается.
Спасибо тебе мужик) такого на ру сегменте ютуба очень не хватает ))❤
Приколько что автор старается по принципу solid спроектировать
Уже больше года пользуюсь featured-slice. Всем советую!
Прошла курс полностью, словила ошибку только в этом месте после проверки на неправильный адрес, пришлось закоментить
словила ошибку только в этом месте после проверки на неправильный адрес, пришлось закоментить
// тайм аут вылетает с ошибкой
// setTimeout(() => {
dispatch({
type: COMMENTS_LOAD,
data: jsonData
});
dispatch(loaderOff());
// }, 1000);
плюс сейчас новая версия спинера и вот эта конструкция в ней уже не работает
import Loader from 'react-loader-spinner';
в остальном все работает, отличный пример
спасибо!!!
Огромнейшее спасибо за все что ты делаешь!
Новичок, если хочешь сразу нормально - начни с ангуляра. Из коробки порядка больше, чем до середины приемов из этого видео. А feature sliced design - держи в голове, думая куда поместить свою фичу. Реакт с вью, сырая поделка, после нескольких лет работы с ангуляр.
только подумал, а тут уже всё есть. Благодарю!
Очень полезное видео. Узнал для себя много нового. Попробую в следующем своем React приложении попробовать архитектуру Feature Sliced Design. Спасибо большое за видео
👍👍👍
Недостатки FSD описывают как раз рецепт того, как нужно подходить к архитектуре проекта при любом подходе. Т.е. если взять любой из сказанных и включить голову, то будет норм. Если взять любой и выключить - будет беда. А так - каждые пол года/год выходят "новые" подходы, хотя как по мне так всё +- одинаковое.
Вообще всё оч красиво на бумаге) На деле, когда проходит 3-4 года и кучу рефакторингов, картина может быть очень печальна.
Бесподобное объяснение 👏
Feature sliced design
Очень крутой разбор, смотрел 3 раза ролик, понимаю что ещё столько всего не знаю. Посмотрел на свои проекты, реально каша) Спасибо огромное!
Ulbi TV просто красава, так держать Тимур - спасибо за обучающее видео
Странно выглядит зачёркивание красным что "мы рассмотрели". Как будто это плохо, мы это вычёркиваем и начинаем разбирать как правильно. Но в конце у нас всё зачёркнуто красным 😁(как в туду проектах, но там про другое). По моему, отмечать галочкой намного удобнее для восприятия. Можно цветными галочками для расстановки акцентов над вариантами решений.
чуть ли не единственный, кто вообще не делает воду и кто делает видосы полезные для миддлов
фигачу стартап на архитектуре "без архитектуры" все довольны, все работает ))) через 5 лет спросите чем все закончилось :D имхо считаю что простая-модульная архитектура вполне себе отлично подходит для небольших проектов с масштабом регионального уровня, и то, только в критически важных местах, по типу авторизации или управления правами доступа и только исходя из этических соображений (по факту эти модули можно вообще отдельно вынести на уровень самостоятельных апк и гонять основу на токенах). В общем мне кажется здесь больше смысл не в том какая у вас архитектура, а как вы провели декомпозицию, в следствии чего получили желаемый, заветный уровень абстрагирования, т.е. имхо независимости.. ну да, это можно назвать архитектурой, но я как-то подсознательно не хочу это делать.. поскольку видимо все течет и меняется во времени, и не применимо к концепции архитектур в принципе. или может просто я не готов к тому, что все более новые и новые архитектуры так быстро появляются :D ..а это уже предмет для философских размышлений. В любом случае здесь решает мнение на основе опыта TL и PM.
Тима, спасибо, смотрим!
Спасибо огромное! Почувствовал себя супергением к концу ролика, иду пробовать fsd)
не хватает музыка для атмосферности))) да, видео не для музыки, но фоновая музыка создаёт атмосферу и темп))
Благодарю! Отличная обзорная экскурсия!
Ещё полгода назад я впервые посмотрел ролик по реакту у тебя, а теперь ебашу мобильную приложуху с килотонным, для меня, стеком и кайфую. Спасибо тебе! Очень нравятся собесы
Привет хотелось бы уточнить на счет FSD.
В примере с entities/user ты показывал папку api, в которой были createUser, updateUser запросы. У меня вопрос почему такие вещи касаются самой entity, а не какой-то фичи из слоя feature или widget по типу createUserForm, updateUserForm?
Потому что все это теоретический умозрительный шаблон, а на практике криворукие кодеры все равно превратят все в кашу)
Огромнон спасибо тебе такую грандиозную работу!
Как всегда топ контент братан! Делай так по чаще! Спасибо за выпуск!
Супер! Огромное спасибо )
Крутейший материал, спасибо огромное! Было бы невероятно круто в дополнение прикладывать ссылки на хорошие примеры проектов или реализовать некий тестовый проект на предложенных архитектурах.
Можно потратить очень много лет, чтобы дойти до этого всего. Просто завидую тем, кто сейчас может это все получить в готовом виде, да еще и таким простым языком. )
Спасибо автору, смог по новому взглянуть на сферу в которую относительно недавно залетел. Здорово, что можно применить FSD в no-code разработке, может немного не в том виде как в классическом программировании, но всё же))
Видос отличный, большое спасибо за огромный пласт информации. Единственное замечание, что последняя архитектура - это скорее не микросервисный подход, а разделение кода на библиотеки. А так прям круто!
Тимур, улбик реально спасибо большое тебе, очень сильно помогаешь. Уверен, что без твоего контента я бы потратил больше времени на обучение. Продолжай в том же духе!
Этот материал уникален для ютуба, спасибо Тимур, было бы интересно когда нибудь увидеть видео по монорепо, можно было бы также turborepo затронуть
Материал уровня крутого платного курса, жаль что я не всё могу осмыслить и применить на данном этапе развития. Спасибо!