Saurus Legacy

『レガシーコード改善ガイド』を読んだ、と言っていいものかどうか。ざっと全体は眺めたつもりだけれど、章を行ったり来たりしながら読んだので、飛ばしたところがないとどうも断言し辛い。

どうしてそんな読み方をしたのか、というと、本書の構成は線形じゃないから。第2部「ソフトウェアの変更」と第3部「依存関係を排除する手法」の各章の間にクロスリファレンスが張り巡らされていて、最初から順番に読んでいくと、説明なしにどんどん新しい用語が使われていく。とてもじゃないけれど、理解できない。

だから、第1部だけはざっと読んで概要を掴んだら、第2部「ソフトウェア」の変更の章タイトルを入り口に必要な範囲を読むのがいいと思う。実際、「序文」の「本書の使い方」もそう勧めている。各章タイトルがFAQのFAになっているから、自分が置かれている状況に近い章が、大抵は見つかるはず。

入り口となる第2部「ソフトウェア」の章タイトルは、次の通り。なかなかユニークなタイトルが並んでいると思う。

6. 時間がないのに変更しなければなりません
7. いつまで経っても変更作業が終わりません
8. どうやって機能を追加すればよいのでしょうか?
9. このクラスをテストハーネスに入れることができません
10. このメソッドをテストハーネスで動かすことができません
11. 変更する必要がありますが、どのメソッドをテストすればよいのでしょうか?
12. 1カ所にたくさんの変更が必要ですが、関係するすべてのクラスの依存関係を排除すべきでしょうか?
13. 変更する必要がありますが、どんなテストを書けばよいのかわかりません
14. ライブラリへの依存で身動きが取れません
15. 私のアプリケーションはAPI呼び出しだらけです
16. 変更できるほど十分に私はコードを理解していません
17. 私のアプリケーションには構造がありません
18. 自分のテストコードが邪魔になっています
19. 私のオブジェクトはオブジェクト指向ではありませんが、どうすれば安全に変更できるでしょうか?
20. このクラスは大きすぎて、もうこれ以上大きくしたくありません
21. 同じコードをいたるところで変更しています
22. モンスターメソッドを変更する必要がありますが、テストを書くことができません
23. どうすれば何も壊していないことを確認できるでしょうか?
24. もうウンザリです。何も改善できません

章タイトルがユニークになるのは、そもそもこの本が取り扱っているテーマがユニークだからだ。そのテーマを一言で表すと、「ユニットテストがないコードを、いかにして保守するか？」だと思う。この本では、そのための大枠の手順として次の5ステップを示し、章タイトルに示す状況でそれをどう進めていくか解説している。

1. 変更点を洗い出す
2. テストを書く場所を見つける
3. 依存関係を排除する
4. テストを書く
5. 変更とリファクタリングを行う

正直に言って、読みやすくはない。でも、2004年にこの本の原著が出版されてから9年、レガシーコードはいっかな減りそうにない。むしろ増えているんじゃないか、という気さえする。

というわけで、類書もないし手元に置いておこうと思う。