テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(writeboost report) ファイルの分割が細かいとの指摘

この前やったファイル分割について, マイクからコメントがあった. 2, 3個のファイルという意味でいったのに, 残念ながら超細かいね. こんな感じでfoldしたらどうだろうか. という内容である.

Unfortunately I think you went too far with all these different small files, I was hoping to see 2 or 3 .c files and a couple .h files.

Maybe fold all the daemon code into a 1 .c and 1 .h ?

The core of the writeboost target in dm-writeboost-target.c ?

And fold all the other data structures into a 1 .c and 1 .h ?

When folding these files together feel free to use dividers in the code like dm-thin.c and dm-cache-target.c do, e.g.:

というコメントが来ることは(プギャーしてるみなさんにとって残念なことに)想定内である. もし, bcacheのようにディレクトリを分離するならば, この形もあると思ったが, マイクの頭の中にはそういうデザインはないのだろう. bcacheはそもそもdevice-mapperではないが, 内容としては近いのでmdの下にあるという背景(実際, メンテナはケント. マイクたちはメンテナではない)があるから, 同じデザインをするのは相当の理由が必要である. 3k程度のコードならば, 1枚か2枚に分割して十分という考え方をしているのだろう.

基本的にアグリーだ. そもそも, ファイルを細かく分割して提示したのは, どういうパーツがあります, aggregateするならばこの単位でまとめていくのがよろしいですよ, という提案のつもりでもあった. 従って, デーモンのコードが分離されていて, データ構造が分離出来そうだとか, そういうことをマイクが理解してくれたのはおれの狙いどおり. おれは遥か上を行っている. 実際に, もう少しまとめるという道もあったし, そっちの方がカプセル化を強く出来る意味があるにはあるので, 反論せず受け入れて十分.

今から, 設計を綿密に考えて, 一気に斬るつもりである. その後, マイクに報告しよう.

ちなみに, カプセル化の他にも, あまりにも細かい単位で分割することは, ファイル追加/削除のリスクが高いというのも欠点である. gitの性質上, この操作は回避したい. 単純なトレードオフであり, マイクがそちらを好むのであれば, マージという目的のために自分の嗜好を諦めることは何の抵抗もない. コミュニケーションのオーバーヘッドも高いですし. おれを始めとして, 早いやつしかいない世界だから, 通常世界の開発とは, 力点が変わってくる. 優秀な人間とだけ働くのはとにかく楽しい. 居場所はやはりカーネルコミュニティにあった.

(追記)
マイクの指摘を踏まえて修正を行い, 報告を行った.

http://www.redhat.com/archives/dm-devel/2013-September/msg00170.html

とても良い設計になったと思う. マイクもこれならば認めてくれるだろう.