Feature Sliced Design — это методология разработки, нацеленная на организацию кода в frontend приложениях таким образом, чтобы он был масштабируем, легко поддерживаемым и удобным для командной работы.
При проектировании приложения с использованием Feature Sliced Design важно обеспечить строгое взаимодействие между слоями, где каждый последующий слой может использовать возможности предыдущих, но не наоборот. Это помогает поддерживать кодовую базу организованной, модульной и легко масштабируемой.
Проект состоит из слоев (layers), в свою очередь слой состоит из слайсов (slices) и уже каждый слайс состоит из сегментов (segments).
LAYERS:
1. Shared (Общее):
Общий слой содержит код, который может быть использован в различных частях приложения. Это могут быть утилиты, хелперы, константы, кастомные хуки. Например, функция форматирования даты
2. Entities (Сущности)
Сущности представляют бизнес-сущности приложения и их логику. Например, в социальной сети сущностями будут пользователи, посты, комментарии. Слой сущностей включает в себя работу с API для получения, обновления и удаления данных, а также кэширование и оптимизацию запросов.
3. Features (Функциональность)
Фичи представляют собой независимые функциональные блоки, которые могут быть переиспользованы в разных частях приложения. В социальной сети примерами фич могут быть: поставить лайк, добавить комментарий
4. Widgets (Виджеты)
Этот слой включает в себя небольшие, переиспользуемые компоненты, которые могут быть встроены в различные части приложения для повышения его интерактивности и улучшения пользовательского опыта. В контексте социальной сети, это могут быть: виджет лайков, виджет комментариев, панель навигации. По сути виджиты объединяют в себе Entities и Widgets в единый блок
5. Pages (Страницы)
Слой страниц определяет компоновку страниц приложения и связывает маршруты с конкретными страницами. Для социальной сети примерами страниц будут: домашняя страница (где отображаются посты друзей), страница профиля пользователя, страница настроек.
6. Processes (Процессы)
Процессы описывают бизнес-процессы приложения, которые взаимодействуют с различными частями системы. Например процесс регистрации: 1. Страница "Выбор способа регистрации"; 2. Страница "Ввод данных"; 3. Страница "Подтверждение регистрации"
- App (Приложение)
Этот слой отвечает за инициализацию приложения и глобальную конфигурацию. Это точка входа в приложение, где происходит настройка роутера, глобальных стилей, сторонних зависимостей (например, Redux Store, Apollo Client для GraphQL).
SLICES:
Slices (слайсы) — это логические разделы или модули внутри каждого слоя, которые группируют связанные функции, компоненты, хуки, типы и другие элементы, относящиеся к определенной доменной области или бизнес-логике. Они помогают изолировать разные аспекты приложения друг от друга, сокращая связанность и упрощая управление кодом.
Пример слайса в слое Entities:
В слое Entities пользователи, посты, комментарии и т.д. будут являться слайсами
Преимущества использования Slices
- Модульность и Переиспользование: Разделение кода на слайсы упрощает переиспользование кода, поскольку каждый слайс содержит всё необходимое для своей работы и может быть легко интегрирован в другие части приложения.
- Упрощение масштабирования: Добавление новой функциональности или расширение существующей становится проще, поскольку вам нужно работать только в рамках соответствующего слайса, не затрагивая остальную часть кодовой базы.
- Лучшая поддерживаемость и читаемость кода: Слайсы помогают организовать код таким образом, что его структура становится более очевидной и легко навигируемой для разработчиков.
- Изоляция и безопасность: Изменения в одном слайсе влияют только на этот слайс, минимизируя риск непреднамеренного влияния на другие части приложения.
SEGMENTS:
В методологии Feature Sliced Design понятие "сегменты" (segments) относится к дальнейшему разделению слайсов на ещё более мелкие и управляемые части. Сегменты позволяют организовать код внутри слайсов таким образом, чтобы улучшить его читаемость, поддерживаемость. Это особенно полезно в больших и сложных приложениях, где управление кодовой базой может стать вызовом.
Пример использования сегментов:
У нас есть слайс User в слое Entities. Этот слайс можно дополнительно разделить на следующие сегменты:
- Model (Модель): Содержит бизнес-логику и управление состоянием для сущности. В контексте слайса User, сегмент модели может включать функции создания, изменения и удаления пользователя.
- Api (API-взаимодействия): Определяет функции и методы для общения с сервером, такие как получение данных пользователя, обновление профиля.
- Lib (Библиотеки): Вспомогательные функции и утилиты, специфичные для слайса User, которые используются в модели или API.
- Types (Типы): Описание типов данных и интерфейсов, используемых в слайсе. В случае слайса User, это могут быть типы для профиля пользователя, данных аутентификации и так далее.
PUBLIC API:
В контексте методологии Feature Sliced Design (FSD), понятие Public API относится к явному определению интерфейсов взаимодействия между различными слоями, слайсами и сегментами приложения. Public API помогает контролировать доступ к функциональности и обеспечивает четкую и удобную точку интеграции для других частей системы.
Public API — это набор экспортируемых функций, классов, компонентов, хуков, типов и прочих элементов, которые предоставлены для использования в других частях приложения. Этот интерфейс определяет, как именно внешние слои и модули могут взаимодействовать с функциональностью данного сегмента, тем самым обеспечивая его инкапсуляцию и защиту внутренней логики.
Преимущества использования Public API
- Инкапсуляция: Public API позволяет скрыть внутреннюю реализацию сегмента или слайса, экспонируя только необходимый для использования интерфейс. Это упрощает взаимодействие между различными частями приложения и повышает безопасность.
- Упрощение рефакторинга: Благодаря четко определенным точкам входа и выхода, модификация внутренней структуры или логики модуля становится проще и безопаснее, поскольку изменения не затрагивают другие части приложения, пока Public API остается неизменным.
- Повышение переиспользуемости: Четко определенное Public API упрощает повторное использование модулей в разных частях приложения или даже в других проектах.
- Документирование: Определение Public API служит отличной документацией для разработчиков, описывая, какие функции и возможности предоставляет модуль или слой.
Когда лучше использовать Feature Sliced Design:
- Сложные и крупные проекты: Когда у вас есть большое приложение с множеством функций и пользовательских сценариев, Feature Sliced Design помогает организовать код таким образом, чтобы его было легче поддерживать и масштабировать.
- Командная разработка: Если над проектом работает несколько разработчиков или команд, методология помогает минимизировать конфликты в коде, делает его более предсказуемым и понятным для всех членов команды.
- Переиспользование кода: В случае, если предполагается, что многие компоненты или функции приложения будут переиспользоваться в разных частях приложения или даже в других проектах, Feature Sliced Design предоставляет четкую структуру для их организации.
- Постепенная миграция или рефакторинг существующего проекта: Когда нужно модернизировать устаревший кодовую базу, подход позволяет делать это постепенно, модуль за модулем.
Когда использование может быть неоправданным:
- Маленькие и простые проекты: Для небольших приложений или прототипов, где структура и сложность кода ограничены, внедрение полноценной методологии может быть излишним и увеличить начальные затраты времени на планирование и настройку.
- Проекты с ограниченным сроком жизни: Если проект разрабатывается для одноразового использования или тестирования идеи, где скорость разработки важнее долгосрочной поддержки и масштабируемости, более гибкие или простые подходы могут оказаться предпочтительнее.
- Команды, не знакомые с методологией: Если команда разработчиков не имеет опыта работы с Feature Sliced Design и сроки проекта не позволяют тратить время на обучение и адаптацию, это может замедлить процесс разработки. В таких случаях может потребоваться весомое решение о необходимости вложения времени в изучение методологии перед ее внедрением.
Использование методологии Feature Sliced Design может быть очень полезным для многих проектов, но как и любая другая архитектурная практика, она имеет свои сценарии, где она наиболее эффективна, а также ситуации, когда ее применение может быть неоправданным.
В заключение, выбор методологии зависит от множества факторов, включая размер и сложность проекта, опыт команды, а также текущие и будущие требования к приложению. Feature Sliced Design предлагает хорошо структурированный подход к разработке, который может значительно упростить управление сложными проектами и командную работу, но его внедрение следует взвешивать исходя из конкретных потребностей и условий.
