Transcription
Дизайн с разрезанными функциями — одна из самых популярных архитектур фронтенда. Отличная документация, активное сообщество, более 2 тысяч звезд на официальном репозитории. Но действительно ли он так хорош, как все думают? В этом видео мы оценим FSD по пяти критериям хорошей архитектуры, чтобы увидеть, что он делает хорошо, где терпит неудачу и что мы можем использовать вместо него. [музыка] Если вы здесь впервые, меня зовут Дима. Я старший фронтенд-разработчик с восьмилетним опытом. Я руководил командами, провел тонны собеседований, обучал разработчиков, >> [музыка] >> и на этом канале мы говорим об архитектуре фронтенда, системном дизайне и других продвинутых темах фронтенда. Теперь перейдем к слайдам. Прежде чем мы рассмотрим дизайн с разрезанными функциями, давайте поймем проблемы, которые он пытается решить. Дизайн с разрезанными функциями позиционирует себя как решение трех распространенных проблем архитектуры фронтенда. Во-первых, масштабируемость. По мере роста проекта кодовая база становится труднее поддерживать. Дизайн с разрезанными функциями пытается решить это с помощью строгих слоев, которые поддерживают порядок, даже когда проект растет и в команду приходит больше разработчиков. Во-вторых, нечеткие границы. Когда вы добавляете сложную функцию, не всегда понятно, куда должны идти ее части, особенно если у проекта нет четкой архитектуры. Дизайн с разрезанными функциями устанавливает четкие правила относительно того, куда должен идти каждый тип кода. По крайней мере, так заявляет архитектура. На практике это может быть не так ясно, но мы вернемся к этому позже. И в-третьих, независимость команды. Когда несколько разработчиков работают над одной и той же кодовой базой, они часто мешают друг другу. FSD использует инкапсулированные срезы, так что в теории разные разработчики могут работать над разными функциями, не создавая конфликтов. Существуют и другие архитектурные шаблоны, так почему же FSD стал настолько популярным? Я вижу здесь несколько причин. Во-первых, у него хорошая документация. Официальный сайт включает примеры, специфичные для фронтенда, что редкость для архитектурных шаблонов. Большинство других архитектурных подходов, таких как чистая архитектура, например, или шестиугольная архитектура, были разработаны для бэкенда. У них есть документация, но без примеров для фронтенда. Другая причина: он дает командам общий словарь. Вместо того чтобы каждая команда создавала свои собственные названия папок, FSD предоставляет вам набор терминов, таких как слои, срезы и сегменты. Если разработчики знают FSD, они уже знают эти термины, и они должны быть одинаковыми во всех проектах FSD. Кроме того, он был разработан специально для фронтенда. Чистая архитектура и объектно-ориентированное проектирование пришли из мира бэкенда. FSD был создан с учетом фронтенд-приложений с самого начала. И, наконец, он дает вам пошаговые рецепты. Для каждого типа кода, такого как UI, бизнес-логика или вызовы API, есть предопределенное место, куда он идет. В теории разработчикам не нужно тратить время на решение, куда поместить новый код. На практике это работает не идеально, но мы обсудим это позже. Итак, FSD звучит хорошо на бумаге, но является ли он на самом деле хорошим архитектурным шаблоном? Чтобы ответить на этот вопрос, сначала нам нужно понять, как мы определяем, что делает архитектуру хорошей в целом. Нет какой-то официальной структуры для оценки этого, но есть пять правил, которые я лично считаю важными при оценке любой архитектуры, и мы применим все пять к FSD. Вот эти пять правил. Во-первых, высокая связность. Простыми словами, сколько файлов вам нужно открыть, чтобы изменить одну функцию, и насколько близки эти файлы друг к другу? Если весь код, связанный с одной функцией, например, функцией карточки в интернет-магазине, сосредоточен в одном месте, связность высока, и это то, что нам нужно. Если он разбросан по многим папкам, связность низкая. Во-вторых, низкая связанность. Когда вы меняете один модуль, влияет ли это на другие модули? Когда связанность низкая, вы можете изменить один модуль, не нарушая другие. Это хорошо, потому что это делает архитектуру более надежной. Когда связанность высокая, одно изменение может нарушить модули, которые вы не ожидали, потому что это делает архитектуру более хрупкой. В-третьих, обнаруживаемость. Может ли разработчик быстро найти код, который ему нужно изменить, не тратя слишком много времени на поиск? В-четвертых, соответствие ментальной модели. Сопоставляются ли бизнес-функции напрямую с папками в кодовой базе, или разработчикам нужно выяснять, к какой архитектурной категории относится функция, прежде чем они смогут найти или написать код? И в-пятых, инкрементальное внедрение. Можете ли вы начать с простой структуры и добавлять больше правил по мере роста проекта, или вам нужно настроить полную структуру с первого дня, даже если проект слишком мал? Мы проверим FSD по каждому из этих правил. Привет всем, быстро скажу, у меня есть бесплатное руководство по современным архитектурным шаблонам фронтенда. Оно охватывает самые популярные подходы и когда их использовать. Ссылка в описании. И если вы серьезно относитесь к архитектуре фронтенда, у меня есть курс. Не просто теория, а с реальной практикой применения. Он также охватывает системный дизайн, CI/CD, тестирование и многое другое. Проверьте advancedfrontcourse.com. Ссылка также в описании. Прежде чем мы оценим FSD, позвольте мне кратко представить, как он работает. Каждый проект FSD включает три основных строительных блока: слои, срезы и сегменты. Слои — это папки верхнего уровня в вашем проекте. FSD определяет шесть из них. Первый слой — app, глобальная настройка, провайдеры и маршрутизация. Далее, pages, один маршрут на страницу. Widgets, составные блоки UI, которые используют несколько страниц, такие как заголовок или боковая панель. Features, действия пользователя, такие как вход или поиск. Entities, бизнес-объекты, такие как пользователь или продукт с их данными и базовым UI. И shared, повторно используемые утилиты, компоненты UI и конфигурации. Важно, чтобы shared не включал бизнес-логику. Внутри каждого слоя вы разделяете код по бизнес-домену. Так, внутри features, у вас могут быть отдельные папки для корзины, аутентификации и поиска. Это называется срезами. А внутри каждого среза код организован по технической роли. UI для компонентов, model для бизнес-логики, API для получения данных и lib для утилит. Это называется сегментами. Здесь вы можете увидеть, как это работает в деталях. Каждый слой содержит свои срезы, а каждый срез разделен на сегменты. Структура последовательна по всему проекту. Далее, правила импорта. FSD имеет строгие правила относительно того, что может импортировать что. Нижние слои не могут импортировать из верхних слоев, поэтому features могут импортировать из entities, но entities не могут импортировать из features. Pages могут импортировать из widgets, но widgets не могут импортировать из pages. Причина этого — стабильность. Если бы entities могли импортировать из features, то изменение features могло бы нарушить entity, а эта entity могла бы использоваться многими другими features. Сохраняя импорты только вниз, изменения в верхнем слое не влияют на нижние слои. Таким образом, вы можете вносить изменения, не нарушая случайно другие части приложения. Существует также правило импорта внутри одного слоя. Одна entity не может импортировать из другой entity, и одна feature не может импортировать из другой feature. Есть исключения из этого правила, но мы обсудим их позже. Вот пример кода, показывающий, как слои, срезы и сегменты соотносятся с фактическими файлами и каталогами. Вы можете увидеть папку app вверху, затем pages, widgets, features, entities и shared, каждая из которых содержит срезы, организованные в сегменты. Еще одна вещь о том, как работает FSD, — это публичный API. Каждый срез имеет файл index.js, который определяет, что другие части приложения могут использовать из этого среза. Внутренние файлы — компоненты внутри UI, вспомогательные функции внутри lib — другие части приложения не должны импортировать их напрямую. Таким образом, каждый срез работает как черный ящик. Пока экспорты из index.js остаются прежними, вы можете изменить что угодно внутри среза, не влияя на остальную часть приложения. Первый импорт на слайде правильный. Он проходит через index.js. Второй достигает непосредственно папок внутри среза, что означает, что если этот внутренний файл переместится или будет переименован, импорт сломается. Решения дизайна FSD выглядят хорошо в теории. Слоистая архитектура предотвращает циклические зависимости. Именование основано на бизнес-доменах. Публичный API обеспечивает инкапсуляцию, и каждый слой имеет четкое назначение, потому что разработчики не тратят время на решение, куда поместить новый код. Но теория и практика не всегда совпадают. Применим наши пять правил хорошей архитектуры к FSD. Вот что мы ожидаем. Высокая связность, низкая связанность, обнаруживаемость, соответствие ментальной модели и инкрементальное внедрение. Давайте пройдемся по ним по одному. Начнем с высокой связности. Это касается того, насколько близки файлы, связанные с одной функцией, друг к другу в проекте. Простыми словами, сколько файлов вам нужно открыть, чтобы изменить одну функцию? Прежде чем говорить о связности в FSD, давайте убедимся, что мы четко понимаем, что на самом деле означают связность и связанность, потому что эти два понятия часто смешиваются. Связность означает объединение вещей, которые меняются вместе. Если вы модифицируете функцию, и весь связанный код находится в одном месте, это означает, что у нас высокая связность. Если он разбросан по многим папкам, это низкая связность. Связанность измеряет, являются ли разделенные модели или функции действительно независимыми. Если изменение одной модели влияет на другую, они сильно связаны. Если вы можете изменить одну модель, не нарушая другие, связанность низкая, и это то, что нам нужно. Так это выглядит на практике. Вот функция корзины и функция заказа. Мы хотим высокой связности внутри каждой из этих моделей. Все связанные файлы должны быть близко друг к другу, но у нас также есть связанность между этими моделями, потому что хук use cart использует что-то из order utils. Связанность между моделями нежелательна, но она встречается в реальной жизни. Что мы хотим сделать, так это свести эти связи к минимуму. Теперь давайте посмотрим, как выглядит кнопка "добавить в корзину" в парадигме FSD. Представьте, что разработчику нужно исправить эту кнопку. В FSD основная логика находится в папке features add to cart. Но чтобы понять полную картину, разработчику может потребоваться проверить до трех или четырех разных слоев. Компонент кнопки может находиться в слое виджетов. Модель данных корзины находится в сущностях. Вызов API может быть в общем слое. А логика функции находится в слое функции. Таким образом, даже для одной небольшой функции вам приходится перемещаться по нескольким папкам в разных слоях. Когда это происходит, мы говорим, что код функции разбросан по проекту, или, другими словами, функция имеет низкую связность. Но почему низкая связность внутри функции является проблемой для архитектуры? Во-первых, когнитивная нагрузка. Чем более разбросаны файлы, тем выше когнитивная нагрузка. Вместо того чтобы смотреть на одну папку, вам нужно держать на экране и в уме несколько файлов и пути к ним. Во-вторых, скрытые зависимости. Когда код для одной функции находится в нескольких слоях, изменение в одном слое может нарушить код в другом, и вы можете этого не заметить. В-третьих, медленный обзор кода. Та же когнитивная нагрузка применима и к рецензентам. Им нужно держать полную картину в голове, что делает обзоры дольше и увеличивает вероятность пропуска чего-либо. И в-четвертых, более сложное онбординг. Для новых разработчиков проблема когнитивной нагрузки еще больше. Они тратят еще больше времени, пытаясь понять, как работает функция. Слева код одной функции разделен между несколькими слоями. Это низкая связность. Справа весь код остается внутри одного среза. Это пример высокой связности. Но в то же время, поскольку FSD разделяет код по срезам внутри слоев, он имеет хорошую связность внутри каждого среза. Проблема в том, что эти срезы все еще находятся в разных слоях. Таким образом, мы можем сказать, что связность FSD низкая на уровне функций. Следующее правило — низкая связанность. Когда вы меняете одну модель, влияет ли это на другие модели? Когда связанность высокая, мы также называем это неявными зависимостями между моделями. Так что, когда вы думаете, что одна модель не должна зависеть от другой, но на самом деле это так, это то, что мы называем неявными связями. И если в проекте много таких связей, мы говорим, что он имеет высокую связанность. Вот пример. Представьте, что мы разрабатываем приложение для электронной коммерции, и у нас есть кнопка "добавить в корзину", которая нужна на трех разных страницах: страница списка товаров, главная страница и страница с деталями товара. Как вы разделяете эту кнопку в FSD? Давайте рассмотрим три возможных решения. Первый вариант — создать дубликаты кнопок. Мы берем один и тот же компонент кнопки и создаем копию для каждой сущности. В результате мы получаем нулевую связанность между моделями. Каковы преимущества этого подхода? Он соответствует правилу импорта FSD. Нет перекрестных импортов между срезами. И поскольку каждая функция имеет свою собственную кнопку, они могут настраивать ее независимо. Это невозможно, если они все используют одну и ту же. Но делая это, вы нарушаете принцип DRY. Если логика кнопки изменится, скажем, вам нужно добавить состояние загрузки, например, вам нужно добавить ее в каждую из них, и вам нужно знать, где она используется, или помнить, что вам нужно проверить, где она используется, прежде чем вносить какие-либо изменения. Второй вариант — одна общая кнопка. В этом сценарии мы создаем связанность между моделями, потому что у нас есть одна основная модель с кнопкой, а другие модели становятся зависимыми от нее. Преимущество этого подхода — единый источник истины. Таким образом, у нас есть только одна кнопка и одно место для обновления. Но правило перекрестных импортов FSD. Связанность между моделями — одна из проблем, которую FSD пытался предотвратить с помощью правил импорта, и у них есть причина для этого. Если вам все еще иногда нужны перекрестные импорты между функциями, FSD имеет официальное решение — нотацию @x. Вы создаете папку @x внутри среза, и эта папка повторно экспортирует код из другого среза. Таким образом, идея в том, что если мы не можем полностью предотвратить перекрестные импорты, давайте хотя бы сделаем их видимыми и явными. Вот как это работает. Слева эти импорты выглядят как обычные импорты, ничего особенного. Вы не можете сказать, что это перекрестные импорты сущностей, пока что-то не пойдет не так. Справа папка @x делает зависимость видимой в коде, что не решает проблему связанности, но по крайней мере делает связь между моделями видимой. Третий вариант — поместить кнопку в общий слой. Поскольку shared — это самый нижний слой, любой компонент в приложении может импортировать из него. Этот подход не нарушает правило перекрестных импортов, и любой компонент может использовать кнопку, но есть другая проблема. Правила FSD гласят, что общий слой не должен содержать бизнес-логику, только повторно используемые компоненты, утилиты и конфигурации. Кнопка "добавить в корзину" — это бизнес-логика. Она знает о корзинах и продуктах. Поэтому помещение ее в shared противоречит правилам FSD. Другая проблема с общим слоем заключается в том, что разработчики продолжают помещать туда код, который не подходит ни к одному слою или нужен в нескольких местах, и shared становится огромным. К сожалению, у меня нет хорошего решения этой проблемы, кроме как помещать туда только код, который в целом нужен в нескольких местах. Если мы вернемся к официальному решению, предложенному документацией FSD, мы увидим, что, хотя @x делает связи между моделями видимыми, волшебства нет. Это все равно увеличивает связанность, и в результате архитектура становится более хрупкой. Эта диаграмма показывает, как выглядит идеальная связность и связанность. Нижний правый раздел имеет высокую связность и низкую связанность. Это то, что нам нужно. Верхний правый — это "божественный объект". Все тесно связано в одном месте, и одна модель делает слишком много. Нижний левый — деструктивное разделение. Вещи разделены, но без четкой цели. А верхний левый — плохо выбранные границы. Модели зависят друг от друга, и связанный код разбросан. Если мы поместим FSD на эту диаграмму, он не окажется в худшем разделе, но и не достигнет идеального. Связность на уровне срезов хорошая, но связность на уровне функций ухудшает ситуацию. В то же время связанность не так плоха. FSD по умолчанию предотвращает перекрестные импорты и пытается сделать связи видимыми через нотацию @x. Итак, давайте обобщим связность и связанность для FSD. По связности — низкая. FSD разделяет код по техническому типу, что означает, что бизнес-доменная логика для одной функции разбросана по нескольким слоям. По связанности — я бы сказал, что она естественная. Перекрестные импорты изначально запрещены, что звучит хорошо, но на практике было введено решение @x, потому что строгая изоляция оказалась слишком ограничивающей. Нотация @x делает зависимости видимыми и явными, но она все равно увеличивает связанность между срезами. Следующее — обнаруживаемость. Можете ли вы найти, где находится ваш код, не тратя слишком много времени на поиск? Помните ситуацию, когда вам нужно исправить ошибку или добавить новую функцию? Насколько сложно было найти все файлы, связанные с этой моделью? Вот что такое обнаруживаемость. Когда обнаруживаемость хорошая, разработчики быстро находят нужный им код. Они открывают проект, смотрят на структуру папок и быстро понимают, куда идти. Когда обнаруживаемость низкая, разработчики тратят время, пытаясь выяснить, какие файлы за что отвечают. Зная структуру FSD, мы видим явную проблему с обнаруживаемостью. Определения слоев перекрываются, поэтому один и тот же компонент может находиться в разных слоях. Один разработчик считает, что строка поиска — это функция, другой — что это виджет. Другая проблема, которую мы обсуждали ранее, — низкая связность. Тот факт, что файлы, связанные с одной моделью, находятся в разных слоях, еще больше ухудшает обнаруживаемость. И это также затрудняет обзор кода. Вместо обсуждения фактического изменения рецензенты и авторы pull request тратят время на обсуждение того, к какому слою принадлежит код. Проблема FSD и подобных архитектур в том, что у них есть несколько вариантов для одного компонента. Например, в простой слоистой архитектуре любой элемент UI — это компонент, а любое действие — это хук. В FSD вы можете быть уверены. Вот пример. Возьмем компонент строки поиска. Это функция, виджет или часть сущности? Разные команды могут ответить на этот вопрос по-разному. И даже в рамках одной команды разные разработчики могут поместить его в разные слои. И это связано с проблемой связности. Поскольку файлы, связанные с одной функцией, находятся в разных слоях, их поиск занимает больше времени. Низкая связность ухудшает обнаруживаемость. Следующий критерий — соответствие ментальной модели. Соответствует ли структура папок тому, как команда думает о продукте? Когда бизнес-функции напрямую сопоставляются с папками, разработчики открывают папку функции и быстро находят все, что им нужно. Когда это не соответствует, разработчикам требуются дополнительные шаги. Им нужно выяснять, к какой архитектурной категории относится функция, прежде чем они смогут найти или написать код. Например, данные корзины находятся в сущностях, действие добавления в корзину — в функциях, отображение корзины — в виджетах, а API — в общем. Каждый раз нужно переводить между бизнес-концепциями и архитектурными категориями. В этом примере мы можем увидеть разницу. Слева вы видите высокоуровневую структуру FSD. Пример технически ориентированной структуры. На бизнес-языке у нас нет таких вещей, как функции или виджеты. Справа папки названы в соответствии с тем, что делает приложение. Корзина, оплата, пользователь, товары. Таким образом, структура проекта отражает бизнес-структуру приложения. Правая сторона также является примером того, что мы называем "кричащей архитектурой". Идея в том, что структура папок должна говорить вам, что делает приложение, а не какой шаблон или технологии оно использует. Достаточно открыть проект и увидеть по названиям папок, что это приложение для электронной коммерции с корзиной, платежами и управлением пользователями. Конечно, соответствие ментальной модели не является абсолютным. Чем больше времени разработчику требуется, чтобы понять связь между бизнес-концепциями и кодом, тем хуже это соответствие. И наоборот. Когда разработчику достаточно взглянуть на высокоуровневую структуру приложения и понять, о чем идет речь, мы говорим, что у него высокое соответствие ментальной модели. FSD организует код по техническим категориям: сущность, функция, виджет. В зависимости от того, как долго разработчик работает над проектом, ему может потребоваться больше или меньше времени, чтобы найти конкретную часть кода в проекте, который использует технические категории. И последнее — инкрементальное внедрение. Насколько легко начать проект, добавлять новые функции и развивать проект со временем? Когда инкрементальное внедрение хорошее, вы можете начать с простой структуры и добавлять больше правил по мере роста проекта и когда команда замечает конкретные болевые точки. Без этого вам нужно настроить всю архитектуру с первого дня, еще до того, как вы узнаете, как будет выглядеть проект. Так почему это важно? Потому что в начале проекта вы не знаете, какой будет окончательная форма приложения. Требования меняются, добавляются и удаляются функции, и архитектура должна адаптироваться. Вот как это выглядит. Когда мы начинаем новый проект, вот как мы ожидаем, что он пойдет. Мы собираем требования, проектируем архитектуру и выпускаем. Но в реальности требования меняются после того, как мы уже что-то построили. Поступают новые требования, и вы понимаете, что архитектуру нужно скорректировать, и это может происходить несколько раз в течение жизненного цикла проекта. Приложение, которое должно было быть маленьким и простым, становится намного больше. Верно и обратное. Приложение, которое планировалось как большой проект, может не выжить. Что важно для нас, архитектура — это не одноразовое решение. Она меняется вместе с продуктом. Это структура принятия решений о том, как мы обновляем архитектуру вместе с изменениями проекта. Вы создаете продукт, поступают новые требования, и на каждом шаге вы спрашиваете: "Влияет ли это на архитектуру? Нужно ли нам больше структуры или, возможно, меньше, потому что некоторые части были удалены?" Вот как мы можем понять, что нам нужно изменить архитектуру. Разработчики начинают мешать друг другу, возникают неожиданные побочные эффекты от изменений, и работать над проектом в целом становится труднее. Дело в том, что мы меняем архитектуру на основе обратной связи, которую получаем от системы. Важно, чтобы мы могли начать с малого. Во-первых, потому что требования могут значительно измениться в будущем. И во-вторых, потому что проект может просто не выжить. Но FSD работает не так. Как вы можете видеть, нам нужно применять FSD очень рано, сразу после этапа первоначальных требований. Нет его облегченной версии. Шесть слоев, срезы, сегменты и правила импорта с самого начала. И это нормально для проектов, где мы знаем, что все это понадобится. Но для скольких проектов мы можем быть уверены с самого начала, что они не изменятся в будущем? Скажем так, FSD имеет плохую инкрементальную адаптивность. Итак, давайте обобщим, что FSD делает хорошо и где он работает не так хорошо. С положительной стороны, FSD обеспечивает хорошую связность на уровне срезов. Внутри одного среза код хорошо организован. Он предотвращает циклические зависимости благодаря строгим правилам импорта. А документация и инструменты лучше, чем у большинства альтернатив. Но с отрицательной стороны, связность на уровне функций низкая. Код для одной бизнес-функции разбросан по нескольким слоям. Существует проблема классификации. Один и тот же компонент может подходить для нескольких слоев, и разработчики могут не соглашаться относительно его размещения. Структура ориентирована на технологии, а не на бизнес, и она не поддерживает инкрементальное внедрение. Вам нужна полная структура с самого начала. Итак, если у FSD есть эти проблемы, что мы можем использовать вместо него? Я хочу показать вам как минимум две альтернативы для небольших и более крупных приложений. Первый вариант — слоистая архитектура. Так же, как и FSD, она организует код по технической ответственности. Слоистая архитектура не ограничивает нас количеством слоев, но для веб-проектов мы обычно используем три. Компоненты для UI, сервисы для бизнес-логики и API для доступа к данным. Таким образом, она также не следует правилам "кричащей архитектуры", но она более гибкая и простая, потому что мы можем начать всего с трех слоев и добавлять больше при необходимости. На практике у нас обычно есть три слоя плюс страницы для маршрутизации и общий слой для повторно используемых утилит и компонентов. Как вы можете видеть, структура намного проще, чем FSD. Как слоистая архитектура оценивается по нашим пяти правилам? Слоистая архитектура имеет низкую связность. Она организует код по типу, как и FSD. Код вашей функции разбросан по папке UI, папке логики и папке API. По связанности нет строгих правил импорта, поэтому это зависит от дисциплины команды. Обнаруживаемость в целом хорошая. У нас есть несколько слоев, каждый с одной четкой целью. Новым разработчикам легче ориентироваться. Соответствие ментальной модели низкое. Это технически ориентированная структура, а не ориентированная на бизнес. И инкрементальное внедрение хорошее. Вы можете начать с двух или трех слоев и добавлять больше структуры, когда вам это нужно. Таким образом, слоистая архитектура хорошо подходит для небольших и средних проектов. Она не будет хорошо масштабироваться для больших приложений, но она дает вам простую отправную точку. Второй вариант — вертикальные срезы. Это очень похожая структура на FSD, но наоборот. Первое, что вы видите, — это функции, а не технические слои. Вот как это выглядит на практике с нашим примером корзины. У нас есть три среза и три технических слоя внутри каждого среза. У нас также есть страницы для маршрутизации и общий слой для повторно используемого кода. Вот пример того, как мы можем масштабировать вертикальные срезы дальше. Если одна функция становится слишком большой, мы можем добавить внутренние срезы внутри нее. Теперь давайте оценим вертикальные срезы по нашим пяти правилам. Вертикальные срезы имеют высокую связность. Весь код для одной функции находится в одной папке. Например, вы открываете папку корзины, и вы видите все, что связано с корзиной. По связанности — то же самое, что и слоистая архитектура. Нет строгих правил, обеспечивающих независимость функций. Перекрестная связанность функций возможна и зависит от дисциплины команды. Обнаруживаемость хорошая. Весь код для одной функции находится в одной папке, поэтому вы знаете, куда смотреть. И нет неоднозначных имен, таких как сущности и функции, поэтому вы не запутаетесь, где что находится. Соответствие ментальной модели высокое. Структура папок соответствует тому, как команда думает о продукте. Бизнес-функции напрямую сопоставляются с папками. Инкрементальное внедрение также хорошее. Вы можете начать с нескольких папок и добавлять срезы, когда проект растет и вам нужна большая структура. Таким образом, вертикальные срезы хорошо подходят для средних и крупных проектов. Основной риск — это перекрестная связанность функций, но это проблема дисциплины команды, а не структурная. Итак, давайте обобщим, что мы узнали сегодня. Во-первых, инкрементальное внедрение. FSD не поддерживает начало с малого. Он требует полной структуры, шести слоев, срезов, сегментов и инструментов импорта с первого дня. Для многих проектов это слишком много структуры слишком рано. Во-вторых, FSD решает некоторые реальные проблемы. Например, циклические зависимости, но он также создает новые. Код для одной функции разбросан по нескольким слоям, а перекрывающиеся определения слоев приводят к несогласованному размещению кода. В-третьих, для небольших проектов слоистая архитектура — хорошая отправная точка. Для средних и крупных проектов вертикальные срезы обеспечивают высокую связность и структуру, которая лучше соответствует бизнес-структуре и помогает разработчикам ориентироваться в коде. Оба подхода поддерживают инкрементальное внедрение. Вы можете начать с минимальной настройки и добавлять структуру по мере необходимости. И в-четвертых, FSD стал популярным, потому что он заполнил реальный пробел. До FSD не было специфичных для фронтенда архитектурных шаблонов с официальной документацией и примерами для фронтенда. Документация и общий словарь очень ценны, даже если, по моему мнению, архитектура не идеальна. Ни для небольших, ни для крупных приложений. На этом все на сегодня. Надеюсь, это было полезно. И прежде чем вы уйдете, создание этих видео занимает много времени, поэтому, если вы можете поддержать меня лайком и подпиской на канал, это будет очень полезно. И увидимся в следующем видео. Пока.