レガシーコードを理解して改善するための、さまざまなプラクティス
さて、いかがだったでしょうか。今回は『レガシーコード改善ガイド』で取り上げている原則やプラクティスの一部を紹介しました。
その他にもこの本では、テスト用クラスの命名規約、メソッドの影響範囲を特定するため影響スケッチ（effect sketch）、アーキテクチャを説明するための白紙のCRC（naked CRC）、安全に変更作業を行うためコンパイラまかせ（Lean on the Compiler）やシグニチャの維持（Preserve Signatures）など、レガシーコードを理解して、改善するためのさまざまなプラクティスを紹介しています。
ユニークな第2部の章タイトル
最後に、本書のユニークな特徴を1つ紹介しておきましょう。本書は3部構成になっていますが、第2部の章タイトルは非常にユニークです。以下に実際の章タイトルのいくつかを示します。
- 第6章：時間がないのに変更しなければなりません
- 第11章：変更する必要がありますが、どのメソッドをテストすればよいのでしょうか？
- 第14章：ライブラリへの依存で身動きが取れません
- 第23章：どうすれば何も壊していないことを確認できるでしょうか？
- 第24章：もうウンザリです。何も改善できません
- I Don't Have Much Time and I Have to Change It
- I Need to Make a Change. What Methods Should I Test?
- Dependencies on Libraries Are Killing Me
- How Do I Know That I'm Not Breaking Anything?
- We Feel Overwhelmed. It Isn't Going to Get Any Better
これは、レガシーコードと闘う開発者からのFAQ（よくある質問）を想定した表現にしているためです。皆さんも第2部の目次から思い当たるタイトルを探して、そこの章から読み始めてみてはいかがでしょうか。
終わりに
5回にわたって『レガシーコード改善ガイド』の内容を紹介してきました。本書の良いところは、「テストのないコードがレガシーコード」と定義し、まずはテストで保護するために、最善の設計よりも現実的な解決を目指していることです。この連載を読んで興味を持っていただいた方は、ぜひ『レガシーコード改善ガイド』に書かれているノウハウやテクニックを身につけ、保守開発に役立てていただければと思います。
