XP考案者のKent Beck著のTidy First?という本を読んだ。
サマリ
Tidyingは日本語で言うところの整理といったところか。 本文ではリファクタリングの一種で誰もNOと言わない可愛らしいちっちゃなリファクタリングという意味合いで使っている。
3つのパートに別れてて下記の内容に分かれている
- Part 1: Tidyingのパターン (What)
- Part 2: Tidyingのマネージメント (When, How)的な内容
- Part 3: Tidyingの理論 (Why)
気になった箇所
PRの分け方の話
- Tidyingと動作に関する変更でPull Requestsは分ける、また、PR毎のTidyingの個数 (バッチサイズ)はできるだけ少なくすべき
- そうするとPRレビューの負担が大きくなるデメリットがでてくるが
- だからといってバッチサイズを小さくせず、PRレビュー自体の負担を下げるようにすべき。
- そのために、Tidyingに関するPRはレビューなしも実験してみるといい。
- うまくいかなかったらどうやったらうまく行くか研究する。
いつTidyするか
- しない (Never)：今後変更することがありえない場合
- 将来的に (Later)：短期的にはないが長期的に見れば費用対効果がある場合
- 機能的変更の後 (After)：将来的にTidyする場合のコストが大きい場合
- 機能的変更の前 (First)：Tidyしたら変更がしやすくなる場合
理論的な話
ソフトウェアのコスト ≒ 変更のコスト ≒ 結合度の大きさである、と説いている。 Tidyすることで結合度を小さくできることはできるが、その作業にもコストがかかる。結合度の大きさによるコストと結合度を減らす作業よるコストのバランスを見てTidyしていく必要がある。
所感
むやみやたらにTidyだったりするのではなくてソフトウェアのコストとそのコストを下げる作業にかかるコスト合わせて考えたときにコストが下げられるかどうかがTidyするかどうかの肝になる。 ただ、その常にその判断を適切にすることは難しいと感じており、まずは明らかにTidyしたほうがよさそうなときだけ試してみようと思う。 (自分は普段からTidyするクセはあるがやり過ぎな傾向がある)
3章は結構斜め読みしていたのでまた気が向いたらしっかり読んでみようと思う。
よくわからなかったので後で調べる箇所
- Chapter 4: New Interface, Old Implementation 古い実装を新しいインターフェースに適応させるために古い実装のラッパーを作る？よくわからん。