「レガシーコード改善ガイド」のススメ
第5回：レガシーコードを攻略するための原則とプラクティス

邦訳版『Working Effectively With Legacy Code』の重要トピックを紹介

レガシーコードを理解して改善するための、さまざまなプラクティス

　さて、いかがだったでしょうか。今回は『レガシーコード改善ガイド』で取り上げている原則やプラクティスの一部を紹介しました。

　その他にもこの本では、テスト用クラスの命名規約、メソッドの影響範囲を特定するため影響スケッチ（effect sketch）、アーキテクチャを説明するための白紙のCRC（naked CRC）、安全に変更作業を行うためコンパイラまかせ（Lean on the Compiler）やシグニチャの維持（Preserve Signatures）など、レガシーコードを理解して、改善するためのさまざまなプラクティスを紹介しています。

ユニークな第2部の章タイトル

　最後に、本書のユニークな特徴を1つ紹介しておきましょう。本書は3部構成になっていますが、第2部の章タイトルは非常にユニークです。以下に実際の章タイトルのいくつかを示します。

• 第6章：時間がないのに変更しなければなりません

　 - I Don't Have Much Time and I Have to Change It

• 第11章：変更する必要がありますが、どのメソッドをテストすればよいのでしょうか？

　 - I Need to Make a Change. What Methods Should I Test?

• 第14章：ライブラリへの依存で身動きが取れません

　 - Dependencies on Libraries Are Killing Me

• 第23章：どうすれば何も壊していないことを確認できるでしょうか？

　 - How Do I Know That I'm Not Breaking Anything?

• 第24章：もうウンザリです。何も改善できません

　 - We Feel Overwhelmed. It Isn't Going to Get Any Better

　これは、レガシーコードと闘う開発者からのFAQ（よくある質問）を想定した表現にしているためです。皆さんも第2部の目次から思い当たるタイトルを探して、そこの章から読み始めてみてはいかがでしょうか。

終わりに

　5回にわたって『レガシーコード改善ガイド』の内容を紹介してきました。本書の良いところは、「テストのないコードがレガシーコード」と定義し、まずはテストで保護するために、最善の設計よりも現実的な解決を目指していることです。この連載を読んで興味を持っていただいた方は、ぜひ『レガシーコード改善ガイド』に書かれているノウハウやテクニックを身につけ、保守開発に役立てていただければと思います。