Сегодня я открываю продажи на свой первый платный курс "FSD — полный курс"
Да, я решил первый курс сделать по одной из самых непопулярных тем из возможных. Почему?
На самом деле, я очень люблю FSD. Ну или правильнее – я люблю ту концепцию, которую FSD реализует.
Мы так часто концентрируемся на инструментах, которые используем. Но архитектура наших приложений – намного более влияющая штука. Она влияет на сроки, на комфорт разработки, расширяемость, сложность.
Вот реально, на React, Redux, react-query, zustand можно написать клубок неподдерживаемого месива. С плохой архитектурой любой инструмент ужасен. И, наоборот, с хорошей архитектурой на любом инструменте можно написать хорошо.
Но где эта хорошая архитектура??? Как её делать? Читать эти большие и сложные книги? Clean Architecture, Синяя, Зелёная, Красная книга по DDD? Даже если всё это прочитать, вообще не понятно как с фронтом справляться. В общем, это сложно и не каждому доступно.
И тут появляются ребята – авторы FSD и говорят: «А давайте застандартизируем архитектуру. Мы не будем пытаться сделать идеально. А попробуем придумать максимально простые, но работающие правила.»
FSD – это классический пример эвристики. неплохая статейка
Как эвристическое правило: "Не спи под сухим деревом" спасает от большого шанса не проснуться утром;
Так и правило: "Не импортируй в shared бизнес код" спасает от большой вероятности нервного расстройства, когда заказчик захотел всё поменять.
И было бы это обычным мнением отдельно взятой команды, но они оформили это в документацию. Делают примеры и собрали большое сообщество людей, которые используют те же правила, и могут поделиться своим опытом
В общем, я считаю феномен FSD большим шагом вперёд. Очень хочу продвигать и развивать эту тему. Буду делать видео по этому поводу и участвовать в развитии.
Да, я решил первый курс сделать по одной из самых непопулярных тем из возможных. Почему?
На самом деле, я очень люблю FSD. Ну или правильнее – я люблю ту концепцию, которую FSD реализует.
Мы так часто концентрируемся на инструментах, которые используем. Но архитектура наших приложений – намного более влияющая штука. Она влияет на сроки, на комфорт разработки, расширяемость, сложность.
Вот реально, на React, Redux, react-query, zustand можно написать клубок неподдерживаемого месива. С плохой архитектурой любой инструмент ужасен. И, наоборот, с хорошей архитектурой на любом инструменте можно написать хорошо.
Но где эта хорошая архитектура??? Как её делать? Читать эти большие и сложные книги? Clean Architecture, Синяя, Зелёная, Красная книга по DDD? Даже если всё это прочитать, вообще не понятно как с фронтом справляться. В общем, это сложно и не каждому доступно.
И тут появляются ребята – авторы FSD и говорят: «А давайте застандартизируем архитектуру. Мы не будем пытаться сделать идеально. А попробуем придумать максимально простые, но работающие правила.»
FSD – это классический пример эвристики. неплохая статейка
Как эвристическое правило: "Не спи под сухим деревом" спасает от большого шанса не проснуться утром;
Так и правило: "Не импортируй в shared бизнес код" спасает от большой вероятности нервного расстройства, когда заказчик захотел всё поменять.
И было бы это обычным мнением отдельно взятой команды, но они оформили это в документацию. Делают примеры и собрали большое сообщество людей, которые используют те же правила, и могут поделиться своим опытом
В общем, я считаю феномен FSD большим шагом вперёд. Очень хочу продвигать и развивать эту тему. Буду делать видео по этому поводу и участвовать в развитии.