Не понимаю термин фича тут.
Если к примеру есть в системе функция создания пользователя, но надо сделать функцию массового создания пользователей, немного изменив логику,
то делается паралелльный код и используются только классы сущности по работе с базой?
Или же где есть возможность переиспользования методов то надо переиспользовать?

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

Здравствуйте, snaphold, Вы писали:

S>Не понимаю термин фича тут.
S>Если к примеру есть в системе функция создания пользователя, но надо сделать функцию массового создания пользователей, немного изменив логику,
S>то делается паралелльный код и используются только классы сущности по работе с базой?
S>Или же где есть возможность переиспользования методов то надо переиспользовать?
S>т.е. основная непонятка feature — это полностью паралелльный код, чтобы не тратить много времени на понимание как врезаться и что можно переиспользовать из существующего
S>или же имеется вида фича для заказчика просто, а код надо переиспользовать?

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

Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, snaphold, Вы писали:

S>>Не понимаю термин фича тут.
S>>Если к примеру есть в системе функция создания пользователя, но надо сделать функцию массового создания пользователей, немного изменив логику,
S>>то делается паралелльный код и используются только классы сущности по работе с базой?
S>>Или же где есть возможность переиспользования методов то надо переиспользовать?
S>>т.е. основная непонятка feature — это полностью паралелльный код, чтобы не тратить много времени на понимание как врезаться и что можно переиспользовать из существующего
S>>или же имеется вида фича для заказчика просто, а код надо переиспользовать?

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

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

Здравствуйте, snaphold, Вы писали:

S>Не понимаю термин фича тут.
S>Если к примеру есть в системе функция создания пользователя, но надо сделать функцию массового создания пользователей, немного изменив логику,
S>то делается паралелльный код и используются только классы сущности по работе с базой?
S>Или же где есть возможность переиспользования методов то надо переиспользовать?

Feature — это про то, что именно является драйвером изменений в разработке, что именно определяет дизайн системы, либо его изменения. Так domain driven (design) ставит во главу углза предметно-ориентированность, т.е. объекты домена и отношения между ними (фичи не рулят, они вторичны), data driven (design) ориентируется на данные и отношения между ними.
А FDD говорит, что именно фичи будут рулить процессом разработки, т.е. все будет подчинено им.

S>т.е. основная непонятка feature — это полностью паралелльный код, чтобы не тратить много времени на понимание как врезаться и что можно переиспользовать из существующего
S>или же имеется вида фича для заказчика просто, а код надо переиспользовать?
фичи — это вообще не про то, как должен использоваться код. Это о том, что если для реализации фичи надо будет все сломать и построить заново, то так тому и быть. Разумеется, это вульгарное объяснение, т.к. разработка базовой модели должна предвосхищать работу над фичами.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, snaphold, Вы писали:


S>>т.е. основная непонятка feature — это полностью паралелльный код, чтобы не тратить много времени на понимание как врезаться и что можно переиспользовать из существующего
S>>или же имеется вида фича для заказчика просто, а код надо переиспользовать?
S>фичи — это вообще не про то, как должен использоваться код. Это о том, что если для реализации фичи надо будет все сломать и построить заново, то так тому и быть. Разумеется, это вульгарное объяснение, т.к. разработка базовой модели должна предвосхищать работу над фичами.

так получается ничего не мешает построить домен и фичи над доменом?

только непонятно как это выглядит архитектурно.
к примеру если в DDD был контролер из которого вызывался репозиторий, то тут просто CreateUserFeature которая внутри состоит из кучи подключаемых по возможности фич?

Если не затруднит просто пример кода могли бы накидать в вариента FDD и что-то другое

Здравствуйте, snaphold, Вы писали:

S>>фичи — это вообще не про то, как должен использоваться код. Это о том, что если для реализации фичи надо будет все сломать и построить заново, то так тому и быть. Разумеется, это вульгарное объяснение, т.к. разработка базовой модели должна предвосхищать работу над фичами.

S>так получается ничего не мешает построить домен и фичи над доменом?
Построение базовой модели (на бумаге) — первичный этап FDD. Наверняка туда войдет и домен и данные (или их схема).

S>только непонятно как это выглядит архитектурно.
S>к примеру если в DDD был контролер из которого вызывался репозиторий, то тут просто CreateUserFeature которая внутри состоит из кучи подключаемых по возможности фич?
у DDD нет и не может быть исключительного права владения над контроллером и репозиторием. Т.е. они могут быть использованы при любом стиле разработки. Точно так же, как и тесты можно писать не только лишь в ТДД.

S>Если не затруднит просто пример кода могли бы накидать в вариента FDD и что-то другое
Конечно затруднит. Мы ведь не о микроуровне (коде) говорим, а о разнице процессов разработки.

Вот водопадная модель говорит нам о том, что надо сначала все выдумать в голове, задокументировать и лишь потом писать код. ФДД говорит о том, что в общих чертах пишем базовую модель, потом начинаем приделывать фичи, о которых на первом этапе задумывались, но не уделяли им слишком много времени.

Как это отразить в примере кода на форуме — я не знаю.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, snaphold, Вы писали:

S>>Не понимаю термин фича тут.
S>>Если к примеру есть в системе функция создания пользователя, но надо сделать функцию массового создания пользователей, немного изменив логику,
S>>то делается паралелльный код и используются только классы сущности по работе с базой?
S>>Или же где есть возможность переиспользования методов то надо переиспользовать?

S>Feature — это про то, что именно является драйвером изменений в разработке, что именно определяет дизайн системы, либо его изменения. Так domain driven (design) ставит во главу углза предметно-ориентированность, т.е. объекты домена и отношения между ними (фичи не рулят, они вторичны), data driven (design) ориентируется на данные и отношения между ними.
S>А FDD говорит, что именно фичи будут рулить процессом разработки, т.е. все будет подчинено им.
Насколько я знаю, Feature-driven — это не столько про разработку, сколько про управление требованиями. И противопоставляется он scenario-based design.
Фича обычно трактуется как некоторый отдельный фрагмент функциональности, типа "система должна давать пользователю вносить наличные деньги на счёт".
Сценарии были изобретены для того, чтобы избежать появления вороха фич, которые сами по себе пользы не приносят. Типа "скачать шаблон заявки" отдаёт заявку в PDF, а "загрузить заявку" принимает документ в RTF. И вроде каждая фича сделана и протестирована успешно, а заполнить заявку по шаблону не получается.

Оборотной стороной дизайна по сценариям является негибкость системы: если в feature-based разработке конкретные сценарии достигаются комбинированием фич, и проектирование ведёт вменяемый архитектор (или команда архитекторов), то N фич комбинируются от N² до 2^N способами, порождая примерно такое же количество сценариев.
А если разработка ведётся исключительно по сценариям, то сценариев будет ровно столько, сколько задокументировано, ни больше ни меньше.
Если сказано "пользователь находит заявку по номеру заявки" — всё, не ждите поиска по контрагенту или позициям в заявке.
Попытка потребовать что-то типа "давайте сделаем поиск по произвольной части документа, в стиле гугл" тут же упирается в возражение "это не сценарий; в нашем процессе разработки есть только сценарии. Выньте да положьте нам сценарий, в котором пользователю нужен поиск по произвольной части документа". И продакт менеджмент либо сдаётся, либо вынужден изобретать 100500 сценариев вида "пользователь хочет найти заявку, в которой он заказывал позицию X", "пользователь хочет найти заявку, в которой он заказывал у контрагента Y" и так далее. И всё ещё нет гарантии, что инженеры не сделают 100500 кнопок "поиск по позиции", "поиск по контрагенту", и т.д., с разными формами.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>А FDD говорит, что именно фичи будут рулить процессом разработки, т.е. все будет подчинено им.
S>Насколько я знаю, Feature-driven — это не столько про разработку, сколько про управление требованиями. И противопоставляется он scenario-based design.
Это как посмотреть. На TDD тоже можно посмотреть так, что оно будет про управление требованиями. Я не хочу здесь возражать, но у гибких ребят написано что это

Feature-Driven Development (FDD) is a client-centric, architecture-centric, and pragmatic software process

http://agilemodeling.com/essays/fdd.htm

S>Фича обычно трактуется как некоторый отдельный фрагмент функциональности, типа "система должна давать пользователю вносить наличные деньги на счёт".
S>Сценарии были изобретены для того, чтобы избежать появления вороха фич, которые сами по себе пользы не приносят. Типа "скачать шаблон заявки" отдаёт заявку в PDF, а "загрузить заявку" принимает документ в RTF. И вроде каждая фича сделана и протестирована успешно, а заполнить заявку по шаблону не получается.

Я понимаю, о чем речь. Но в FDD есть целые этапы Build Features List & Plan by Feature, которые, по всей видимости, должны подразумевать процесс выбора фич более рациональный, чем то, что происходит в Спортлото.

S>Оборотной стороной дизайна по сценариям является негибкость системы: если в feature-based разработке конкретные сценарии достигаются комбинированием фич, и проектирование ведёт вменяемый архитектор (или команда архитекторов), то N фич комбинируются от N ² 2^N способами, порождая примерно такое же количество сценариев.
S>А если разработка ведётся исключительно по сценариям, то сценариев будет ровно столько, сколько задокументировано, ни больше ни меньше.
S>Если сказано "пользователь находит заявку по номеру заявки" — всё, не ждите поиска по контрагенту или позициям в заявке.
S>Попытка потребовать что-то типа "давайте сделаем поиск по произвольной части документа, в стиле гугл" тут же упирается в возражение "это не сценарий; в нашем процессе разработки есть только сценарии. Выньте да положьте нам сценарий, в котором пользователю нужен поиск по произвольной части документа". И продакт менеджмент либо сдаётся, либо вынужден изобретать 100500 сценариев вида "пользователь хочет найти заявку, в которой он заказывал позицию X", "пользователь хочет найти заявку, в которой он заказывал у контрагента Y" и так далее. И всё ещё нет гарантии, что инженеры не сделают 100500 кнопок "поиск по позиции", "поиск по контрагенту", и т.д., с разными формами.

Тут уже речь немного о другом. Это не про разработку, а про терки между менеджментом и клиентом, в которых ориентация процесса вторична (фичи/сценарии, либо что-то еще). И тут мне сложно выбрать сторону, т.к. с одной стороны клиент может передавливать с хотелками, мешая реализовать основные сценарии, а с другой — менеджмент может прикрывать процессом свою палочную (по кол-ву фич/сценариев) мотивацию.

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