Rename "features" layer [ru]

[noveogroup-amorgunov]

Привет! Если кратко, предлагаю переименовать в каких-нибудь будущих релизах слой features на другое название (например, actions, interactions или usecases).

• Фичи в моем понимании дословно лучше всего переводится как "возможности" и за пределами методологии подразумевает под собой совершенно другое. В методологии же слой отвечает за пользовательские действия. Я больше года использовал фичи - как виджеты (что собственно многие до сих пор и делают), а виджеты просто как слой композиции несколько фичей. Любое другое название слоя на корне обрубит путаницу. В своих пет проектах я бывает явно переименовываю слой в features@usecases, чтобы дать больше контекста этому слою и просто не путаться)
• Сейчас название слоя (features) совпадает с названием методологии, поэтому может создаться ложное представление, что это главный слой в методологии, хотя это не так.
• В первых версиях методологии фичи предназначались для другого (https://github.com/feature-sliced/documentation/blob/rc/feature-driven/FAQ.md , Feature - self-contained, user-facing, (maybe) reusable, complex, with specific logic module), что тоже может путать людей.

Если переименование невозможно (слишком страшный breaking change), то я бы подумал, как лучше для пользователей доносить то, что фичи в FSD это не то, к чему вы привыкли за пределами методологии.

[azinit]

Привет! Да, так исторически сложилось, что фичи оказались слишком сложные в понимании юзеров и FSD в целом
(хотя казалось, что это база - но потом появились виджеты, которые куда лучше подходят для старотового улучшения архитектуры проекта)

И любой feature-based подход стремится содержать в себе папку features в которой по факту могут быть либо виджеты, либо сущности - все зависит от конкретного подхода

В нашем случае мы уже давно поняли, что слои должны появляться в проекте постепенно, и в зависимости от болей команды
(что доносим в докладах и стараемся выкладывать в доке)

В новой версии доки (которую скоро релизнем), этот момент тоже хотим обозначить, в том же туториале:
#574 (comment)

[azinit]

Фичи в моем понимании дословно лучше всего переводится как "возможности" и за пределами методологии подразумевает под собой совершенно другое. В методологии же слой отвечает за пользовательские действия. Я больше года использовал фичи - как виджеты (что собственно многие до сих пор и делают), а виджеты просто как слой композиции несколько фичей.

Именно про это я говорю. Есть самые разные feature-based подходы (тот же feature-driven) где фичи могут быть виджетами
Есть где фичи могут быть сущностями - каждый по вкусу себе выбирает

Но в контексте FSD мы в том числе хотим обрубить эту путанницу явно разграничив понятия
(widgets- про виджеты, entities - про сущности, а если дошли до того что юзкейзы-фичи конкретные нужно унифицировать в приложении - используйте features)

Как ни парадоксально но да - features был самым базовым слоем в методологии, а теперь его сложнее всего понять
Но это не плохо ни для FSD, ни для команд - просто каждая команда должна для себя решать, в каком объеме затаскивать FSD себе в проект (и нужно ли вообще, достаточно ли болей от архитектуры)

Скину еще ссылку на доклад, где говорится про эту проблему
https://youtu.be/dtjULd469Ng?t=4357

[noveogroup-amorgunov]

Почитаю туториал и послушаю доклад, спасибо)

[noveogroup-amorgunov]

Еще кейс по теме, есть так называемые featureToggle (featureConfig). Так он вообще сбивает с толку, так как он никак не относится к слою features. Но когда по FSD пытаешься его интегрировать в проект, то начинается сильная путаница в наименованиях.

Пример пул реквеста на пет проекте: noveogroup-amorgunov/nukeapp#12

[azinit]

У нас про это статья отдельная есть)
https://feature-sliced.design/docs/about/understanding/naming