1つのFeatureとはなにか
(その抽象度における)利用者視点での価値単位や認知単位、と言えるのではないか？mrsekut.icon
そのため、PBFではディレクトリが深くなるたびに、「feature」として指したいものが変わる
あるいは、featureにも抽象度がある、とも言える
N階層のfeatureは、N+1階層のfeatureを組み合わせることで構成できる
「N階層のfeatureを作りたい」という要求に応えるための価値単位がN+1階層でのfeature
具体的に考える
feature/の直下(第1階層)は、そのプログラムのユーザが必要とする価値単位と揃える
Cosenseなら、第1階層にnoteが存在し、
その下にeditor、
更にその下にcarretやline
が存在するというイメージ
目的と手段
見積もりの本なので、PBFとはぜんぜん違う粒度かも知れないが、参考までに
「フィーチャ」という言葉を本書では、ソフトウェアの機能、特性や特徴、性能目標、見た目や使い勝手など、いわゆる「売り文句」などを総称する言葉として使っている
フィーチャは要求仕様、機能要件、大機能、ユースケースといった言葉が指すものとよく似ている
しかし、これらとフィーチャとの決定的な違いは、フィーチャはユーザーにとってのソフトウェアの価値を表現したものであり、ユーザーに直接価値を提供するものだということだ
フィーチャとはユーザーにとっての価値なので、フィーチャには性能目標やセキュリティといったいわゆる非機能要件も含まれる
たとえば、ワープロのアプリケーションであれば、文章校正機能はフィーチャである
業務システムのバックエンドサーバーであれば、1 分間あたりの最大処理能力はフィーチャだ
コンパイラならば最新の言語仕様に完全準拠していることがフィ ーチャである
Web アプリケーションならば、ストレスなくアプリケーションを使えるユーザーインターフェイスはフィーチャになる
一方、プリンターに赤インクを装填できることは機能であって、フィ ーチャではない
この場合は「フルカラーで印刷できること」がフィーチャである
この塩梅、むずいよねmrsekut.icon
オンラインショッピングのサイトに商品選択画面、注文確認画面、支払画面、注文完了画面があった場合、各画面はそれぞれ機能ではあるがフィーチャではない
ショッピングサイトのフィーチャは「欲しい商品を注文できること」である
ソフトウェアを使う側の視点から記述している、という点が重要である
実践してみて、生じている問題
PBFの置き方の問題
featureとしてディレクトリを分けた時に、
magazineのディレクトリの中に、itemに関するものが含まれる、という状況が生じる
magazineという機能が消えれば、このitemの機能も消えるべきなので、合っている気もする
しかしEntityから見れば、変なディレクトリに入っていることになる