[ARCHIVED] Формулировка определения "feature"

[azinit]

Дискуссия закрыта, см выводы по #78

---

---

---

См. начало дискуссии

Если вкратце - есть ощущение, что мы по-разному понимаем, что есть фича

Хотелось бы (в целом):

• В фичах лежит код, который несёт бизнес ценность.
• Фича должна принести пользу конечному пользователю, в идеале достаточно маленькую, чтобы можно было компонировать
• Фича отражала часть бизнес-логики
• Фича была самодостаточной, user-facing, (возможно) реюзабельной, комплексной и несущей определенную логику

При этом есть разные мнения "как разбить / выделить фичу"

Как минимум - следующие:

1. По тому, как они выглядят и примерно работают
   posts-list, post-details

   При этом фичи "разбухают", и есть камень в огород претензия, что они "не несут бизнес-ценность"

2. По названию модели
   posts

   Во многих случаях без такой интерпретации никуда, но опять же - есть риск разбухнуть, плюс поломать абстракции (особенно когда у нас будет еще папка entitites)

3. Одна фича разбивается по другим абстракциям (чтобы как раз нести "бизнес-ценность" и быть достаточно маленькой)
   features/.../models, entities

   Иногда кажется логичным, но с таким подходом (лично у меня), возникает кучу вопросов, в том числе вы (@sergeysova , @karina-drummer ) сами подмечаете, что в таком случае логика по features/../models/ и entities размазывается, и без переименования (models => entities) остается много вопросов (хотя как по мне вопросов становиться только больше :D)

---

📣 Приглашаю к холивару дискуссии!

В прошлый раз на этом остановились

[azinit]

[azinit]

@ilyaagarkov

Пока не могу придумать пример, когда в фиче должна быть папка lib. Все таки lib это код не связанный с бизнесом, тогда как фича должна содержать только бизнесовый код

1. Ты говоришь скорее про shared/lib (т.е. т.к. он shared - он не связан с БЛ почти, но т.к. lib - это инфраструктурные решения/хелперы)
2. А если мы в целом относимся к lib по типу - то это ведь почти структурированный набор хелперов, верно? (это как отличать shared/ui и features/foo/ui)
   • И в зависимости от абстракции где находится - решает задачи только для своего типа (не лезет в ui например), но в соответствии со своей абстракцией-родителем

   • т.е. либо общие хелперы для проекта - (shared/lib)
   • либо хелперы для этой entity (entities/lib)

[azinit]

@ilyaagarkov

Да, само собой - не всегда у тебя в фиче будет lib, но мы предлагаем так делить (по крайней мере я с @niyazm524 ), поскольку вчерашний человек который сначала делил по store/users , сможет сейчас делить наоборот по **/users/store

UPD: Т.е. это понятно и для новых людей, и понятно тебе как разрабу (да тебе мб проще будет импортить ui/lib если они будут на самом верху - но не будет ли это во вред методологии?)

[azinit]

@martis-git
Еще мне понравилась наша мысль с обсуждения что "Фича определяется в момент использования, как и контекст функции в JS"

@ilyaagarkov

Звучит красиво, но есть ощущение, что это будет избыточно для большенства фич.
То есть это можно оставить как рекомендацию для случаев когда это нужно

Хотя может я просто мысль не до конца понял

Согласен, мы тоже пока не до конца понимаем)

В большинстве случаев это мб и рили будет "ту мач", но я пока вижу две интерпретации:

• "У тебя есть фича (или другая абстракция), и ее польза и ценность будет определена в момент использования (на странице/процессе - или в целом более высокой абстракции)"
• "У тебя есть абстракции-типы components, lib, api. Но их применение, цели и польза будут определяться в зависимости от абстракции-функциональности, в которой она находится (Яркий пример: shared/components и features/{foo}/components)"

Это к вопросу опять - почему в методологии должно быть слово feature-***

[azinit]

@ilyaagarkov но спасибо за замечания, т.к. они позволили хорошо сформулировать мне некоторые вещи)

Обсудим позже с нашим комитетом, и в целом

[azinit]

Lib это что-то, что помогает строить entties, features, process (наверное). Что можно причислить к lib:

• ui-kit
• helpers (Ramda like)
• либу форматирования валют
• и подобные

Либы не должны зависеть друг от друга, но могут встречаться исключения.

@binjospookie тож приглашаю к некст итерации дискуссии)

[azinit]

#18 (reply in thread)

[binjospookie]

про entities прям хорошо. могу лишь додать пример: form. некая сущность, объединяющая state-manager (ff, например) и UI-kit. Позволяющая строить любую форму на основе входящих данных (json с полями)

Чтобы такая сущность стала фичей -- надо додать данных. На основе контекста данных (это про аутентификацию, фидбек, оплату) определяется контекст фичи.

[ilyaagarkov]

мне все таки кажется что entities это не про абстрактные понятие как form или filters.

Как я вижу развитие всех этой движухи, entities отпочковались именно от features, в результате того что фичи наподобие features/post приводили к необходимости импортов одних фич в другие. То есть какая то часть того что считалось features перешли в entities.
Но как и features, entities все еще должны быть максимально близко к бизнесу.

[azinit]

@ilyaagarkov

Как я вижу развитие всех этой движухи, entities отпочковались именно от features, в результате того что фичи наподобие features/post приводили к необходимости импортов одних фич в другие.

Соглашусь, т.к. до этого

• либо создавали оркестрацию фич для их кросс-коммуникации (кластеры или на уровне страницы)
• либо выносили в третью фичу (которую было незашкварно заимпортить)

Сейчас же ребята (@sergeysova , @karina-drummer ) предлагают для этого юзать именно entities
(где будут более оторванные от фичи абстракции, благодаря которым можно разрабатывать изолированные фичи)

мне все таки кажется что entities это не про абстрактные понятие как form или filters.
Но как и features, entities все еще должны быть максимально близко к бизнесу.

Да, и по-моему и я там написал - что entities - это в том числе про БЛ)
Максимально абстрактные у нас - это shared-товарищи

Просто надо (как по мне) понимать разницу и суть:

- features/tasks-filtered-list # юзает `filtered-list`
- features/items-filtered-list # юзает `filtered-list`
- entities/filtered-list # не знает про tasks/items, но может быть адаптирован под использование для них

[ilyaagarkov]

Накину своих мыслей

Я не могу дать четкое определние термину фича, но я попытаюсь ответить на вопрос что такое список фич проекта (upd: в результате все таки пришел к определению =) ).

Список фич проекта это тот набор фич который бы перечислил бизнес, пытаясь описать возможности своего продукта конечному пользователю(в целом это мое понимание слов "код, который несёт бизнес ценность").

При этом если бизнес говорит пользователю "Хей смотри у нас есть стена" - это не фича. Если у нас что-то "есть", то это что-то - entity

Если бизнес говорит "смотри ты можешь писать посты на стене" - написать пост на стене это фича. Действие которое может выполнить пользователь и есть фича.
Тут сразу надо оговориться, что не любое дейсвие которое можеть выполнить пользователь является фичей. Пользователь может перейти на какую то страницу, но это явно не фича. Так что нужно явно выделить какие то критерии

Например

• действия пользователя должны привести к изменению в бд (или любого другого хранилища)
• пользователь должен явно видеть результаты этого изменения (сбор статистики посещеных страниц таким образом не попадает в фичи - хоть в результате действий пользователя и меняется бд, пользователь этого явно не видит) _Данный пример спорный, возможно что сбор статистики это все таки фича =)

Фича содержит в себе информацию о том,

• какие данные нужны для того-го или иного действия (как пример - входящие параметры функциии)
• как валидировать данные
• где взять недостобщие данные (взять что-то из общего state)
• досупна ли данная фича (на пример может ли текущий пользователь писать посты на стене другого пользователя)
• какие данные и как нужно их изменить при действии пользователя

а так же фича может содержать

• компоненты специфичные для конктретной фичи. (Например форма отправки поста или даже какие-то менее значимые компоненты но уникальные для данной фичи)

[azinit]

Хорошая простыня текста вышла)

[azinit]

Ох, на самом деле хорошо вещи расписал с философской стороны (Сущность ~ entities, Действие - features (но есть критерии)

Завтра наверн подробнее гляну еще (т.к. есть что дополнить и обсудить)

Но пока также приглашаю к следующей итерации обсуждения - "Абстракции методологии, их цели и нейминг")

[sergeysova]

Отлично описано. Разве что "сбор статистики" это не фича для потребителя продукта, ведь это детали реализации, как именно она будет сделана — не важно. Важно лишь то, как пользователь будет использовать результаты сбора.
Ведь пока он не может их использовать, для него этого нет.

[sergeysova]

Можно отсюда вытащить немного определений #43