Мы увязли в Feature-Sliced Design

В сфере искусственного интеллекта произошло заметное событие. strannik_k 5 минут назад Мы увязли в Feature-Sliced Design Уровень сложности Средний Время на прочтение 17 мин Охват и читатели 156 Блог компании ИТ-холдинг Т1 ReactJS * Веб-разработка * JavaScript * Проектирование и рефакторинг * Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья —продолжение предыдущей: Мой справочник по Feature-Sliced Design . На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD.

Я разрабатываю на React. js, поэтому статья написана с уклоном на него. Содержание Терминология Допустимо ли нарушать рекомендации FSD?

Технические детали

Зависимость количества слоёв и соблюдения рекомендаций от размера проекта и количества связей между подсистемами Разделение структуры большого проекта на несколько подпроектов Вынесение связанного изолированного кода вне основного проекта Слои entities и features для тонких и толстых клиентов Стоит ли использовать разделение на слои entities, features, widgets, pages? Допустимы ли кросс‑импорты в рамках одного слоя? Вложенные слайсы Группирование по функциональности (по вложенным слайсам) вместо группирования по сегментам Структура слайса с несколькими компонентами интерфейса и моделями Структура слайса для нескольких вариантов одной сущности или очень похожих сущностей Должна ли структура папок отражать архитектуру проекта?

Заключение Терминология Чтобы у нас с вами не было путаницы, я добавил небольшой глоссарий по используемым терминам: Подсистема — группа любых программных сущностей (переменные, функции, объекты, типы), сфокусированная на реализации какой‑либо связанной части приложения. Примеры: утилиты для работы с датой, менеджер модальных окон, страница или связанная группа страниц, любой компонент интерфейса, состоящий из программных сущностей, реализующих его отображение и поведение). Подсистема обычно состоит из вложенных подсистем.

Принцип High Cohesion (высокая связность) . Он гласит, что в одной и той же подсистеме, файле, классе или функции желательно писать только код, предназначенный для решения одной задачи либо связанных или похожих задач. Принцип Low Coupling (низкое зацепление).

Отраслевые последствия

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

Где‑то они помогут, а где‑то — наоборот. Разработчики методологии упоминают, да и в документации FSD написано, что она не является «серебряной пулей». Более того, со временем они приходят к выводу, что те или иные рекомендации часто неэффективны, и она понемногу меняется.

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

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.