『レガシーコード改善ガイド』を読んだ、と言っていいものかどうか。ざっと全体は眺めたつもりだけれど、章を行ったり来たりしながら読んだので、飛ばしたところがないとどうも断言し辛い。どうしてそんな読み方をしたのか、というと、本書の構成は線形じゃないから。第2部「ソフトウェアの変更」と第3部「依存関係を排除する手法」の各章の間にクロスリファレンスが張り巡らされていて、最初から順番に読んでいくと、説明なしにどんどん新しい用語が使われていく。とてもじゃないけれど、理解できない。
だから、第1部だけはざっと読んで概要を掴んだら、第2部「ソフトウェア」の変更の章タイトルを入り口に必要な範囲を読むのがいいと思う。実際、「序文」の「本書の使い方」もそう勧めている。各章タイトルがFAQのFAになっているから、自分が置かれている状況に近い章が、大抵は見つかるはず。
入り口となる第2部「ソフトウェア」の章タイトルは、次の通り。なかなかユニークなタイトルが並んでいると思う。
- 時間がないのに変更しなければなりません
- いつまで経っても変更作業が終わりません
- どうやって機能を追加すればよいのでしょうか?
- このクラスをテストハーネスに入れることができません
- このメソッドをテストハーネスで動かすことができません
- 変更する必要がありますが、どのメソッドをテストすればよいのでしょうか?
- 1カ所にたくさんの変更が必要ですが、関係するすべてのクラスの依存関係を排除すべきでしょうか?
- 変更する必要がありますが、どんなテストを書けばよいのかわかりません
- ライブラリへの依存で身動きが取れません
- 私のアプリケーションはAPI呼び出しだらけです
- 変更できるほど十分に私はコードを理解していません
- 私のアプリケーションには構造がありません
- 自分のテストコードが邪魔になっています
- 私のオブジェクトはオブジェクト指向ではありませんが、どうすれば安全に変更できるでしょうか?
- このクラスは大きすぎて、もうこれ以上大きくしたくありません
- 同じコードをいたるところで変更しています
- モンスターメソッドを変更する必要がありますが、テストを書くことができません
- どうすれば何も壊していないことを確認できるでしょうか?
- もうウンザリです。何も改善できません
- 変更点を洗い出す
- テストを書く場所を見つける
- 依存関係を排除する
- テストを書く
- 変更とリファクタリングを行う
というわけで、類書もないし手元に置いておこうと思う。