Интересная идея, по применению паттернов +- можно разобраться по книге паттерны ооп, там есть таблица) Вот по архитектурам такого не встречал. Наблюдаем очень интересно!
Своя архитектура хорошо получается, когда ты уже знаешь типовые артитектуры. Причем знаешь не просто что это и как юзать, а понимаешь, какие именно проблемы они решают.
Только недавно настрочил пару страниц статьи для хабра на тему фсд и как он конфликтует частично с ООП, как ты выпускаешь ролик где большую часть мыслей озвучиваешь. Я из тех кто любит фсд потому что стандартизация, и готовый настроенный подход, но не разделяю размазывание логики по слоям(очевидно - проблема в том, что не на том проекте применил). Согласен что нужно делать самому, но не было идеи как это правильно организовать. Надеюсь твоя идея разовьется до использования, обязательно попробую. Да и за то что озвучил отчасти решение, спасибо
фсд это вобще методичка, в которой столько бреда и дыр, что у них даже есть страница где они бьют себя палкой первыми, что бы кидали не такие большие камни фдс - это пиар коммерческий проект, созданый ушлыми типами которые не хотят всю жизнь кодить на дядю, а решили стать opensourse бизнесменами и все, эту дичь уже давно все прерарировали и нашли родовые травмы я если использую фсд только как организацию папочек "логики по слоям", это самый смак, где там увидели описание логики я хз, да наверное лучше использовать для организации бизнес логики фсд, чем взять и почитать хотя бы про bounded context и сделать по нему, ведь фсд написали 3 чебурека которых прислал сам господь бог, что бы направить на истинный путь фронэнд и выстрел в голову это называть фсд архитектурой... " - дядя Боб, я тут на тарелке тебе покушать принес, архитектуру от ру комнюнити - на попробуй "
5:49 Все таки нужно разделять локальную и глобальные сложности. Тут автор говорит все по факту, но забывает про локальную. Локальная сложность в этих компонентах по отдельности сильно уменьшается. Конечно общая сложность возрастает, но если у вас и так большой проект то как будто не важно, у вас он неебически сложный или простопиздецнеебически сложный, все равно человеческий мозг не может обработать сложности обоих проектов полностью, но вот по частям он гораздо лучше будет воспринимать хоть суммарно простопиздецнеебически сложный, но по частям простой проект, вместо суммарно неебически сложного и также по частям тяжёлого проекта. Конечно вариант с простыми частями не бесплатный и в том случае тупо кода будет гораздо больше. Если у вас маленький проект или просто не сложный, то и этот минусы декомпозиции будет гораздо ощутимей а тот плюс не будут чувствоватся и эти ваши солиды, чачи и и фсд (хз что это, но как описал автор подходит) вам действительно не нужны
А солид чем не угодил, он же универсальный вне зависимости от выбранной архитектуры, руководствуясь им можно проектировать любые системы, начиная от космического корабля и заканчивая омлетом.
Давно размышлял о том как вообще выглядит хороший код. И в итоге пришел к тому что хороший код для пользователя это код который нормально работает, для компании это код который приносит деньги, для джуна это самый простой и понятный, для сениора это вообще отсутствие кода)). Просто не забывайте задаваться вопросом, а надо ли мне это? Это значительно улучшит вашу жизнью. Желаю всем хорошего кода ;D
потому что надо выкинуть роберта мартина и почитать Стива Макконнелли. Да и все эти SOLID/ООП и т.д. и т.п., стоит для фронтенда переформулировать и переосмыслить ( некоторые люди уже этим активно занимаются) Ну и на все вопросы ответ: Зависит от .... 😀 поэтому создать универсальную таблетку невозможно
Прошу прощения за наивный вопрос, но мне всё же не понятно в каком сценарии отказ от принципов SOLID'а может сделать Ваш проект лучше? Вопрос конечно риторически, если Вам приходят к голову сценарии где это может работать, то скорее всего вам надо перечитать на всякий случай что такое SOLID и зачем он нужен
@@paromovevg а зачем лендинг писать в ООП и главное что там можно написать в ООП стиле? Скрипт для работы с DOM, где обрабатываются клики? То есть я о том, зачем вообще об этом говорить, с тем же успехом написание баш скрипта можно было привести в пример. Но вроде бы проблемы реального программирования препарируются и речь как бы о нем. В общем пример отличный, ни разу не надуманный. 😁
@@paromovevg другими словами, если к Вам придут три джуна, пишущие лендинг, и спросят: "Дорогой Парамовемг, Как писать хороший код?", Ваш ответ будет: Ну во первых, обазятельно весь код надо писать в одном скрипте/функции, потому что Single Responsobility Principle не работает. Во вторых, если надумаете делать функции, то постарайтесь сделать так, чтобы они их поведение МАКСИМАЛЬНО было сложно расширить, но при этом очень легко ИЗМЕНИТЬ (ака сломать) Как то так Вы им ответите?
Тут что то намешано( Solid это как не получить тыкву, с непонятным поведением, ООП это просто парадигма это тоже не архитектуру Ddd это набор принципов и схем для понятного управления ... Намешано все, но непонятно о чем речь. И паттерны проектирования в ту же копилку. Fdd тоже методология. Из архитектур указана только чистая. В общем только понял что в конце призыв к чему то присоединиться, так и нужно было так называть ролик, что за кликбейт то?
У всех своё определение архитектуры. Я опираюсь на определение из Википедии. «Важнейшие решения по организации системы» под это подходят все вышеперечисленные принципы паттерны архитектуры и методологии. Да у них есть своя степень свободы. Тут больше говорилось про ощущение, что беспрекословное следование им может сделать мифический «хороший код»
Там в конце прошлого года и в начале этого вышло несколько книг по архитектуре фронтенда, инфоциган решил их пересказать и заработать, но пока не читал 😅
@@paromovevg я вас сейчас удивлю но "организации системы" разделяется на предметную область и доменную а не каждый срет как хочет, это и отличает Васю который получает 500к+ и может построить систему и петю который получает 80к и кроме формы ему ничего не доверишь если для вас все это мифический код, а не реализация и стремление к созданию: гибкой, расширяемой, прогнозируемой системы веб приложения, то удачи вам на заводе, там все проще а вобще забавно все это читать в веб болоте, когда уже в других отраслях все это база))
Вообще без понятия, что именно вы поразумеваете под понятиями: "разделяется на предметную область и доменную" Как минимум они не на родном языке авторов этих понятий, и одному богу известно в каком из множеств переводов вы это узнали Но вижу в вашем размышлении базовую ошибку: Как будто "гибкость, расширяемость, и прогнозируемость" это единственные метрики о которых нужно думать Как минимум есть ещё: - Стоимость - Производительность Более того -- расширяемость, это следствие сложности. А сложность -- в газах смотрящего (очевидные следствия нейрофизиологии мозга) Вот и получается, что для одних людей будет код: "гибкость, расширяемость, и прогнозируемость" А для других: "Блядь, опять мидлы пришли и кафку для лендоса взяли" Команды и проекты разные. И Архитектура Васи за 500 нужна далеко не всем
@@paromovevg А не кто и не говорит что DDD и чистая архитектура (которые обычно используются вместе), нужны везде, да и никто не говорит, что там нет разночтений и так же нет одной и правильной реализации. Это реально реализации не для маленьких проектов, но в крупных, с ними решается проблема запутанности, не так увеличивается сложность, хотя и там можно очень усложнить. Но по опыту его проще поддерживать, и ошибок уменьшилось в разы, даже тесты стал писать только для число-дробилок, то что нельзя протестировать использованием. Так же проще в коде, который ты не писал и не трогал. Но цена разработки выросла минимум в 2 раза. Но и количество ошибок уменьшились минимум в 5 раз, в части влияния на другой код. Прочитав много книг по ddd у меня небыло понимания, пока я не попал в реальный проект где это использовалось. Потому что ни одна книга не приводит реального кода, в котором можно покопаться. А в части фронтенда, тут все сложнее, есть хороший видос, но без работы с DDD, его можно воспринять как бред (так было у меня)
Потому что когда проект начинают писать 20+ разрабов, то он превращается в кашу. Особенно когда бизнес требования часто меняются, то уже лень переделывать по 5 раз в идеальный вариант
Умиляют все эти 20-летние сеньор разработчики. Нельзя сказать просто, что опыт 6 лет? Не исключено, что эти 6 лет ещё отчасти в институте были и/или на курсах. Когда хочется про ордена, звания говорить, то лучше с достижений начинать
Есть парни в 16 лет которые целой команды стоят, на всех хакатонах первые места берут и могут некоторым сеньерам фору дать) Так что ты молодец парень что в таком возрасте понимаешь глубокий смысл программирования ❤🎉
@@bobyrevvladislav Некоторым сеньорам, которым 18 лет разве что. В 16 тебе чистая биология не дает быть профессиональным разработчиком, при любых талантах. Тупо нет тех лет, которые дадут необходимый опыт.
Спасибо, очень качественное видео! В который раз убеждаюсь в ваших навыках подачи материала простым языком
Я люблю реакт!
Интересная идея, по применению паттернов +- можно разобраться по книге паттерны ооп, там есть таблица) Вот по архитектурам такого не встречал. Наблюдаем очень интересно!
Своя архитектура хорошо получается, когда ты уже знаешь типовые артитектуры. Причем знаешь не просто что это и как юзать, а понимаешь, какие именно проблемы они решают.
"Хороший код" - который хорошо читается. Вроде как в "Clean code" эта мысль доносится в процессе чтения
Именно. Буквально вся книга про это.
Не давно столкнулся с тем, что fsd немного завязал руки и пришлось отойти от него.
Ваш совет дельный, спасибо
Очень хорошо! Мое почтение!
Идея отличная, наблюдаю за реализацией
Ничего не понял, но очень интересно!
Я в деле!
Только недавно настрочил пару страниц статьи для хабра на тему фсд и как он конфликтует частично с ООП, как ты выпускаешь ролик где большую часть мыслей озвучиваешь. Я из тех кто любит фсд потому что стандартизация, и готовый настроенный подход, но не разделяю размазывание логики по слоям(очевидно - проблема в том, что не на том проекте применил). Согласен что нужно делать самому, но не было идеи как это правильно организовать. Надеюсь твоя идея разовьется до использования, обязательно попробую. Да и за то что озвучил отчасти решение, спасибо
фсд это вобще методичка, в которой столько бреда и дыр, что у них даже есть страница где они бьют себя палкой первыми, что бы кидали не такие большие камни
фдс - это пиар коммерческий проект, созданый ушлыми типами которые не хотят всю жизнь кодить на дядю, а решили стать opensourse бизнесменами и все, эту дичь уже давно все прерарировали и нашли родовые травмы
я если использую фсд только как организацию папочек
"логики по слоям", это самый смак, где там увидели описание логики я хз, да наверное лучше использовать для организации бизнес логики фсд, чем взять и почитать хотя бы про bounded context и сделать по нему, ведь фсд написали 3 чебурека которых прислал сам господь бог, что бы направить на истинный путь фронэнд
и выстрел в голову это называть фсд архитектурой...
" - дядя Боб, я тут на тарелке тебе покушать принес, архитектуру от ру комнюнити
- на попробуй
"
@@alexpipin3693 У них есть конкретный продукт, за который хотят денег? Любопытно взглянуть:) Кинешь ссылку?
@@modusvivaldiпиар отдельных личностей себя, чтобы отжимать у бизнеса больше бабок на зп и сидеть на проекте над менее ушлыми типами
5:49 Все таки нужно разделять локальную и глобальные сложности. Тут автор говорит все по факту, но забывает про локальную. Локальная сложность в этих компонентах по отдельности сильно уменьшается. Конечно общая сложность возрастает, но если у вас и так большой проект то как будто не важно, у вас он неебически сложный или простопиздецнеебически сложный, все равно человеческий мозг не может обработать сложности обоих проектов полностью, но вот по частям он гораздо лучше будет воспринимать хоть суммарно простопиздецнеебически сложный, но по частям простой проект, вместо суммарно неебически сложного и также по частям тяжёлого проекта.
Конечно вариант с простыми частями не бесплатный и в том случае тупо кода будет гораздо больше.
Если у вас маленький проект или просто не сложный, то и этот минусы декомпозиции будет гораздо ощутимей а тот плюс не будут чувствоватся и эти ваши солиды, чачи и и фсд (хз что это, но как описал автор подходит) вам действительно не нужны
А солид чем не угодил, он же универсальный вне зависимости от выбранной архитектуры, руководствуясь им можно проектировать любые системы, начиная от космического корабля и заканчивая омлетом.
Давно размышлял о том как вообще выглядит хороший код. И в итоге пришел к тому что хороший код для пользователя это код который нормально работает, для компании это код который приносит деньги, для джуна это самый простой и понятный, для сениора это вообще отсутствие кода)). Просто не забывайте задаваться вопросом, а надо ли мне это? Это значительно улучшит вашу жизнью. Желаю всем хорошего кода ;D
Давайте еще и шаблонный код автогенерировать для сконструированной архитектуры.
потому что надо выкинуть роберта мартина и почитать Стива Макконнелли.
Да и все эти SOLID/ООП и т.д. и т.п., стоит для фронтенда переформулировать и переосмыслить ( некоторые люди уже этим активно занимаются)
Ну и на все вопросы ответ: Зависит от .... 😀 поэтому создать универсальную таблетку невозможно
очень амбициозная задача!
Прошу прощения за наивный вопрос, но мне всё же не понятно в каком сценарии отказ от принципов SOLID'а может сделать Ваш проект лучше? Вопрос конечно риторически, если Вам приходят к голову сценарии где это может работать, то скорее всего вам надо перечитать на всякий случай что такое SOLID и зачем он нужен
Сценарий: Проект где три джуна пишут лендинг?
@@paromovevg а зачем лендинг писать в ООП и главное что там можно написать в ООП стиле? Скрипт для работы с DOM, где обрабатываются клики? То есть я о том, зачем вообще об этом говорить, с тем же успехом написание баш скрипта можно было привести в пример. Но вроде бы проблемы реального программирования препарируются и речь как бы о нем.
В общем пример отличный, ни разу не надуманный. 😁
@@paromovevg другими словами, если к Вам придут три джуна, пишущие лендинг, и спросят: "Дорогой Парамовемг, Как писать хороший код?", Ваш ответ будет:
Ну во первых, обазятельно весь код надо писать в одном скрипте/функции, потому что Single Responsobility Principle не работает.
Во вторых, если надумаете делать функции, то постарайтесь сделать так, чтобы они их поведение МАКСИМАЛЬНО было сложно расширить, но при этом очень легко ИЗМЕНИТЬ (ака сломать)
Как то так Вы им ответите?
Тут что то намешано(
Solid это как не получить тыкву, с непонятным поведением,
ООП это просто парадигма это тоже не архитектуру
Ddd это набор принципов и схем для понятного управления
...
Намешано все, но непонятно о чем речь. И паттерны проектирования в ту же копилку. Fdd тоже методология.
Из архитектур указана только чистая.
В общем только понял что в конце призыв к чему то присоединиться, так и нужно было так называть ролик, что за кликбейт то?
У всех своё определение архитектуры. Я опираюсь на определение из Википедии. «Важнейшие решения по организации системы» под это подходят все вышеперечисленные принципы паттерны архитектуры и методологии. Да у них есть своя степень свободы. Тут больше говорилось про ощущение, что беспрекословное следование им может сделать мифический «хороший код»
Там в конце прошлого года и в начале этого вышло несколько книг по архитектуре фронтенда, инфоциган решил их пересказать и заработать, но пока не читал 😅
@@paromovevg я вас сейчас удивлю но "организации системы" разделяется на предметную область и доменную
а не каждый срет как хочет, это и отличает Васю который получает 500к+ и может построить систему и петю который получает 80к и кроме формы ему ничего не доверишь
если для вас все это мифический код, а не реализация и стремление к созданию: гибкой, расширяемой, прогнозируемой системы веб приложения, то удачи вам на заводе, там все проще
а вобще забавно все это читать в веб болоте, когда уже в других отраслях все это база))
Вообще без понятия, что именно вы поразумеваете под понятиями: "разделяется на предметную область и доменную"
Как минимум они не на родном языке авторов этих понятий, и одному богу известно в каком из множеств переводов вы это узнали
Но вижу в вашем размышлении базовую ошибку:
Как будто "гибкость, расширяемость, и прогнозируемость" это единственные метрики о которых нужно думать
Как минимум есть ещё:
- Стоимость
- Производительность
Более того -- расширяемость, это следствие сложности. А сложность -- в газах смотрящего (очевидные следствия нейрофизиологии мозга)
Вот и получается, что для одних людей будет код: "гибкость, расширяемость, и прогнозируемость"
А для других: "Блядь, опять мидлы пришли и кафку для лендоса взяли"
Команды и проекты разные. И Архитектура Васи за 500 нужна далеко не всем
@@paromovevg А не кто и не говорит что DDD и чистая архитектура (которые обычно используются вместе), нужны везде, да и никто не говорит, что там нет разночтений и так же нет одной и правильной реализации. Это реально реализации не для маленьких проектов, но в крупных, с ними решается проблема запутанности, не так увеличивается сложность, хотя и там можно очень усложнить. Но по опыту его проще поддерживать, и ошибок уменьшилось в разы, даже тесты стал писать только для число-дробилок, то что нельзя протестировать использованием. Так же проще в коде, который ты не писал и не трогал. Но цена разработки выросла минимум в 2 раза. Но и количество ошибок уменьшились минимум в 5 раз, в части влияния на другой код.
Прочитав много книг по ddd у меня небыло понимания, пока я не попал в реальный проект где это использовалось. Потому что ни одна книга не приводит реального кода, в котором можно покопаться.
А в части фронтенда, тут все сложнее, есть хороший видос, но без работы с DDD, его можно воспринять как бред (так было у меня)
Потому что когда проект начинают писать 20+ разрабов, то он превращается в кашу. Особенно когда бизнес требования часто меняются, то уже лень переделывать по 5 раз в идеальный вариант
Состояине)
Первый❤🎉
FSD работает у тех, кто работает на ФСБ
Умиляют все эти 20-летние сеньор разработчики. Нельзя сказать просто, что опыт 6 лет? Не исключено, что эти 6 лет ещё отчасти в институте были и/или на курсах. Когда хочется про ордена, звания говорить, то лучше с достижений начинать
Есть парни в 16 лет которые целой команды стоят, на всех хакатонах первые места берут и могут некоторым сеньерам фору дать)
Так что ты молодец парень что в таком возрасте понимаешь глубокий смысл программирования ❤🎉
@@bobyrevvladislav Некоторым сеньорам, которым 18 лет разве что. В 16 тебе чистая биология не дает быть профессиональным разработчиком, при любых талантах. Тупо нет тех лет, которые дадут необходимый опыт.
@@bobyrevvladislav есть такие, но они никакие не синиоры. В программировании связаном с математикой, а не во фронтенде. хдддддддддд
Фронтендер говорит про ООП, выключаем вилео
Ну тебе вообще ролики по программированию лучше не смотреть, раз ты такое пишешь, стажерик😂
@@Jesiksss говори что хочешь, но мы оба знаем кто из нас фронтендер
@@Денис-ж3ф5р я точно знаю, что ты и не программист, так что гуляй🤣
evol(cli) fsd widget widget_name
cd widget/widget_name
evol generate clean_design
Xdddd
Буду с интересом следить за развитием