В каких случаях стоит переводить проект на FSD

Когда мигрировать на Feature-Sliced Design (FSD)

Feature-Sliced Design — это архитектурная методология для организации больших фронтенд-проектов. Но это не серебряная пуля, и переход требует продуманного подхода.

Когда FSD действительно полезна

Проект растёт и усложняется — когда проект перешёл отметку 50+ компонентов или несколько команд работают параллельно, FSD помогает избежать хаоса. Структура слоёв (shared, entities, features, widgets, pages) даёт ясность о том, где находится код.

Много разработчиков в команде — если в проекте работает 3+ фронтенд-разработчиков, FSD предотвращает конфликты. Каждый разработчик работает в своём слое, логика разделена чётко.

Долгосрочная поддержка — когда проект планируется развивать годами, инвестиция в архитектуру окупается. FSD упрощает добавление новых фич без сломов существующей логики.

Сложная бизнес-логика — если у тебя есть сложные фичи с множеством состояний, юзкейсов и интеграций, FSD структурирует эту сложность понятным образом.

Когда FSD может быть overkill

Маленькие проекты (< 10 компонентов) — для лендинга или простого Dashboard, стандартная структура (components, pages, utils) просто и логично. FSD добавит ненужное усложнение.

Стартап на ранней стадии — когда требования меняются каждую неделю, документированная архитектура может замедлить итерации. Лучше сначала решить, что работает.

Один разработчик — если в проекте только ты, FSD не даёт преимуществ. Проще работать с привычной структурой.

Краткосрочный проект — если это временный проект (< 6 месяцев), затраты на миграцию не окупятся.

Структура FSD (слои)

// FSD организует код в слои по глубине влияния:

src/
  shared/           // Переиспользуемые утилиты, UI-компоненты, хуки
    ui/
    lib/
    constants/
  entities/         // Доменные сущности (User, Post, Comment)
    user/
    post/
  features/         // Пользовательские функции (AddComment, LikePost)
    add-comment/
    like-post/
  widgets/          // Композитные компоненты для страниц
    comment-list/
  pages/            // Page-компоненты для маршрутов
    posts/
    user-profile/

Как понять, нужна ли миграция

Признаки, что пора переходить:

• Сложно найти нужный файл (импорты идут с 5+ уровней вложенности)
• Конфликты при мерже PR-ов в одних и тех же папках
• Одна фича затрагивает файлы в разных местах проекта
• Нет ясной линии между бизнес-логикой и представлением
• Новые разработчики долго разбираются в структуре

Если этого нет — FSD может не понадобиться.

Пошаговая миграция

1. Начните с новых фич — не переписывайте всё старое. Новые фичи разрабатывайте в FSD структуре
2. Рефакторьте постепенно — на каждый PR переносите кусок кода в правильные слои
3. Документируйте правила — опишите, какой код в каком слое живёт
4. Обучайте команду — проведите презентацию о новой структуре
5. Не переписывайте всё сразу — это займёт месяцы и создаст много конфликтов

Альтернативы

Если FSD кажется сложной:

• Simpler структура — разделить на components/, pages/, utils/, hooks/
• Barrel exports — использовать index.ts для упрощения импортов
• Монорепо — разделить на отдельные npm-пакеты для разных доменов

Заключение

FSD полезна, но только когда проект это требует. Мигрируй на FSD если:

• Проект большой (100+ компонентов)
• Команда 3+ разработчиков
• Много повторных конфликтов в PR
• Планируется долгосрочная поддержка

Для маленьких проектов оставайся с простой структурой. Не добавляй архитектуру просто так.