書かれていること
ソフトウェア設計についてKent Beckの新刊です。
内容としてはコードの整頓についてについて書かれており、タイトルにあるように、整頓の方法だけでなく「いつやるか」という点にもフォーカスされています。整頓の方法についてはよく他の書籍でも言及されるところだと思いますが「いつか」という観点は新鮮。構成としては、整頓の方法、管理術、理論の順で話が展開されていました。
第１部：整頓
ここでは整頓の仕方について手法をカタログのように紹介していました。リーダブルコードなどでよく見るような内容が多かったです。例としては、下記のような項目について各章にわけて簡潔に説明されています。
- ガード節
- デッドコード
- 凝集の順番
- 説明変数、説明定数
- etc
個人的に印象に残っていた内容だけ少し記載しておきます。
「5章：読む順番」
読む順番を変えるときに、同時に他の整頓をする誘惑に負けないこと、と書かれています。
大事だと思います。修正してる時は、該当箇所付近をよく読むことになるので、別のことも同時に気が付いて触りたくなるのですよね…気をつけます。
「12章：ヘルパーを抽出する」
ヘルパールーチンとして抽出するときに、ルーチンがどのように機能するかではなく、目的にあわせてルーチンに名前をつけましょう。大事。
「13章：ひとかたまり」
細かく分割されているがゆえに理解を妨げるコードの話です。必要な範囲でコードをインライ化して大きな塊し、そこから整頓する。当たり前ではありますが、整頓すると考えると、どうしても分ける方に偏りがちだが、あえて一度塊にして改めて分けると。
確かに、この方が見通しよくなり、よりよい整頓になりそうだと感じました。
第２部：管理術
整頓はリファクタリングへの入り口。整頓を適用できるようになっただけでは、マスターしたことにはならない。「できるからやるべきとは限らない」と書かれている。その上で、２部では、「いつ整頓をはじめるか」「いつ整頓をやめるか」「どのように整頓、コードの構造の変更とふるまいの変更を組み合わせるか」について述べられている。
１部と同様に、各項目で小さい章として分けて書かれている。
２部で特に印象に残っている部分について簡単にまとめておきます。
「16章：分けて整頓する」
プルリクを出す単位は構造の変更と振る舞いの変更で分けよう。「整頓」と「振る舞いの変更」が切り替わるたびに新しいプルリクを作る。焦点を絞ったプルリクであればレビュー速度も上がる。
書かれている通りですね。構造変更と振る舞いの変更が同時に含まれる切り戻しもしにくいし、レビュー時のコストも高くなりますよね。
「19章：リズム」
振る舞いを変更しやすくするための整頓は、１時間以内に終わるような整頓であるべき。それ以上長いと必要な最小の構造変更を見失っている可能性がある。
整頓中に、他に箇所も整頓…としているとあっという間に1時間を超えると思います。確かにその辺の目安として１時間という目安を意識して対応したいですね。時間が掛かっている場合は、過剰に整頓している可能性が高そうです。
「21章：先に整頓、あとに整頓、改めて整頓、整頓しない」
整頓をいつやるか、というかなり大事な内容が書かれている章です。
- 整頓しない
- 二度と変更することがない場合
- 改めて整頓
- 見返りがあったり、小出しに整頓できる場合
- あとに整頓
- 将来の整頓まで待つとコストが高くなる場合
- 先に整頓
- すぐに見返りがある（理解向上、振る舞いの変更が楽になる）
- どのように整頓したらよいかすでにわかっている場合
整頓するタイミングを4パターンにわけて、どのようなケースで、いつ整頓するかを説明してくれています。整頓の利点がどれくらいで得られるか？整頓はどのように償却されるか？といった、あまり普段考えない切り口からの解説もあり、大変興味深い解説でした。
「先に整頓」に偏るが、整頓自体が目的にならないように注意と記述も。気をつけましょう！
第３部：理論
最後の理論の部は、なぜ整頓するのかの理論的な話が書かれていました。
- ソフトウェア設計とは何か
- ソフトウェア設計がソフトウェア開発と運用のコストにどのように影響するか
- 構造への投資のトレードオフ
- ソフトウェアの構造変更や変更の決定判断のための、経済性の原則、人間性の原則
構造の変更とふるまいの変更は、どちらも価値を生み出すが根本的に別の価値であると理解することが大事と書かれています。
また、経済のNPV(正味現在価値)、オプショングリークスの話と関連付けて、コストや価値を考えて整頓をいつやるか、について書かれています。（NPVについては初耳過ぎて、ピンと来なかったので勉強が必要…）「先に整頓し変更」と、「整頓せずに変更」などの比較をしたいときに使える理論の解説といった印象。
ソフトウェア開発コストと結合vs分離の話は、よく目にするような内容でした。
ソフトウェア開発残すとは変更コストとほぼ等しい。そして、変更コストは結合度合いに依存する。つまり、ソフトウェア開発のコストを下げるためには、結合を減らさないといけない。ただし、分離はトレードオフの関係。
これまでの理論とあわせると、結合と分離のどちらのコストを払うか？その時に価値が最大化されるのはどれか？というのを考えながら作ろう、ということだと思いました。
結論としては「先に整頓するか？」は、
- コスト：小さくなるか、発生確率が低下するか
- 収益：整頓によって大きくなるか、入手が早くなるか
- 結合：より少ない要素の変更になるか
- 凝集：変更箇所がより小さく、範囲が狭くなるか
といった４つの観点+自分のプログラミングに平穏と満足、喜びがもたらされるか、で判断すべきと書かれている。
感想
２部や３部の内容については今まで読んだことがない観点で書かれていました。確かに、手法についてはよく見ることがあるが、「いつやるか」というのを真面目に考えたことがなかったので面白かったです。また、整頓へのコストについて議論するときの理論としても、有用な話が多かった印象です。しっかりとやる意味やタイミングの判断について根拠を言語化できるようになるべきだと感じました。最後に「整頓」というワードがよかったなと思いました。リファクタリングというと、大掛かりなイメージになりますが、整頓として、リファクタリングよりも小さいステップとして表現されており、いざやる時にも取っつきやすい印象でした。