1つのFeatureとはなにか
「これを削除するのはどのタイミングか」を考えることは、featureの線引きの指標になる
たまに実装時に削除するタイミングが割と明確に決まっている機能がある
例えば、
期間限定のイベントに関するものである
ページ自体は残すが応募フォームは期間が過ぎたら再利用することはない
この期間だけ表示させたいモーダルである
など
どのタイミングで修正、削除されうるか？を考える
例えば、
RDBMSを別のものに変える時(レア)
代替libararyに入れ替える時(1,2年に1度の頻度で起きる)
業務の仕様が変わった時
こういう場合に、如何に簡単に削除できる状態になっているか
ディレクトリを1つ消せば完了するのか
使われている場所を探して、修正して、時間のかかる確認が必要なのか
これは、実装時の工夫次第で全く異なるコストになる
PBFを良い単位で実装できている場合、これを上手に実践できる
「これを削除する時に同じタイミングで消えるであろうもの」を1つのPackageにすれば良い
様々な側面で見ることができる
変更容易姓、修正のコスト
機能の一覧姓
その機能の仕様変更のされやすさ、使用期間などに依存する
見積もりの本なので、PBFとはぜんぜん違う粒度かも知れないが、参考までに
「フィーチャ」という言葉を本書では、ソフトウェアの機能、特性や特徴、性能目標、見た目や使い勝手など、いわゆる「売り文句」などを総称する言葉として使っている
フィーチャは要求仕様、機能要件、大機能、ユースケースといった言葉が指すものとよく似ている
しかし、これらとフィーチャとの決定的な違いは、フィーチャはユーザーにとってのソフトウェアの価値を表現したものであり、ユーザーに直接価値を提供するものだということだ
フィーチャとはユーザーにとっての価値なので、フィーチャには性能目標やセキュリティといったいわゆる非機能要件も含まれる
たとえば、ワープロのアプリケーションであれば、文章校正機能はフィーチャである
業務システムのバックエンドサーバーであれば、1 分間あたりの最大処理能力はフィーチャだ
コンパイラならば最新の言語仕様に完全準拠していることがフィ ーチャである
Web アプリケーションならば、ストレスなくアプリケーションを使えるユーザーインターフェイスはフィーチャになる
一方、プリンターに赤インクを装填できることは機能であって、フィ ーチャではない
この場合は「フルカラーで印刷できること」がフィーチャである
この塩梅、むずいよねmrsekut.icon
オンラインショッピングのサイトに商品選択画面、注文確認画面、支払画面、注文完了画面があった場合、各画面はそれぞれ機能ではあるがフィーチャではない
ショッピングサイトのフィーチャは「欲しい商品を注文できること」である
ソフトウェアを使う側の視点から記述している、という点が重要である
いわゆる「UseCase」のような感じ？
うーん、ちょっと違いそうmrsekut.icon
UseCaseはあくまでも「プログラムの使用者の視点」であって「ソフトウェアを使う側(User)の視点」ではない
依存に着目
1つのfeature、というのはどういう線引をするのか
例えばFavoriteという概念
post,item,magazineに対して同一の機能がある
Favoriteでまとめるのか、個々に入れてしまうのか
機能単位でみても「お気に入り」「マガジン」のように、どの機能で見るかの話になる
PBFの本来の目的はなにか？を明確にしないと答えられない
感覚ではFavoriteでまとめるのはおかしい気がする
例えばこう分けるのか
magazines
posts
items
favorites
例えばこう分けるのか
magazines
magazineFavorites
posts
postFavorites
items
itemFavorites
例えばこう分けるのか
magazines (中にfavorite機能あり)
posts (中にfavorite機能あり)
items (中にfavorite機能あり)
命名があらければ、1つの機能にあらゆる概念が含みうる
「Scrapboxの機能」と言った時に、
ノート
一覧
で、分ければ荒すぎるし、
[]機能
[$ ]機能
[* ]機能
としていけば、かなり細かくなる
Twitterでも、一番メインとなるフォームのことを
「ツイートの投稿」と言えば荒いし、
@userとか#tagとか、画像の添付とか、GIFとか、アンケートとか、結構いろいろな機能が含まれている
何を懸念しているか？
再利用な話な気がしてきた
データ的には同じ構造のものを、別機能だ、ということでディレクトリを跨ぐと、
変な依存になるか、全く同じ構造を各場所で定義することになる
責務として考えれば、重複があることは問題がないが、
コレのせいで、認知がしづらくなることもありうる
認知の氏やすさのために適用したはずなのに、わかりにくくなるかもしれない？
でもこれは別にPBFに限った話ではないmrsekut.icon
メンタルモデルと言うか、ワークフローというかチャートというか、みたいなものを作りたい
こういう手順にソッテ、考えていけば、同じ機能化どうかを判断できるみたいな
その昨日は別の箇所で使われますか？
その機能に、機能追加があるなら、どうんなものが想定されますか？
その機能を他のプロジェクトに移動させる時に、どんなまとまりになりますか？
ツイッターの例で言えば、webとアプリをまたいだ時に、@userや#タグのいずれかが欠落するということは考えにくい、
だから、これをまとめて1機能と言って問題はなさそう、みたいな
その機能を削除しようとなった時に、どのまとまりで削除しますか？
「それは1つのfeatureと言うにしては大きすぎ、小さすぎ」というのが起こりうる
1つのfeatureと、同じコードの頻出可能性みたいなのも見たい
domain、featureで見方が異なる
だから重複が出てきうるが、それをどこまで許容するか
featureと、Entity定義は必ずしも1対1対応はしない？
featureの方がきめ細かくなるはず
GenrePostPicsどこに入れればいいのか
genreごとに、投稿の一覧を表示するようなものを作る時に、これはどこに含めるべきか？
GenrePostPics?
それ単体で作る？
PostPics?
他にもUserPostPicsとか同じようなものがあるので、これらで一緒にする？
Genres?
Genreで分類しているのだから、Genreの中に入れる？
Posts?
そもそもpostsの内容なのだから、postsの中に入れる？
1機能の指標になりやすそうな考え方
移す時に、どのまとまりで移すか
消す時に、どのまとまりで消すか
libraryに切り出す時に、どのまとまりで切り出すか
UIの機能レベルで分けると増えすぎてしまいそうな気もする
増えてもいいが
A,B,C,Dの4つの機能があって、B,Cのみで共通している裏側の実装、とかの置き場所に困る
実践してみて、生じている問題
PBFの置き方の問題
featureとしてディレクトリを分けた時に、
magazineのディレクトリの中に、itemに関するものが含まれる、という状況が生じる
magazineという機能が消えれば、このitemの機能も消えるべきなので、合っている気もする
しかしEntityから見れば、変なディレクトリに入っていることになる
package by domainではないのか？
featureとdomainの切り口は若干異なるので、
1つのfeatureが、複数のdomainをまたがる、ということが多々起きる
その場合に、どこに置くべきか困る