システム保守の現場でありがちな、構造が複雑で理解できないようなコードに対する分析手法・対処方法について解説。コードを理解し、テストできるようにし、リファクタリングを可能にし、機能を追加できるテクニックを紹介。
もくじ情報：第１部　変更のメカニズム（ソフトウェアの変更；フィードバックを得ながらの作業；検出と分離；接合モデル；ツール）；第２部　ソフトウェアの変更（時間がないのに変更しなければなりません；いつまで経っても変更作業が終わりません；どうやって機能を追加すればよいのでしょうか？；このクラスをテストハーネスに入れることができません；このメソッドをテストハーネスで動かすことができません；変更する必要がありますが、どのメソッドをテストすればよいのでしょうか？；１カ所にたくさんの変更が必要ですが、関係するすべてのクラスの依存関係を排除すべきでしょうか？；変更する必要がありますが、どんなテストを書けばよいのかわかりません；ライブラリへの依存で身動きが取れません；私のアプリケーションはＡＰＩ呼び出しだらけです；変更できるほど十分に私はコードを理解していません；私のアプリケーションには構造がありません；自分のテストコードが邪魔になっています；私のオブジェクトはオブジェクト指向ではありませんが、どうすれば安全に変更できるでしょうか？；このクラスは大きすぎて、もうこれ以上大きくしたくありません；同じコードをいたるところで変更しています；モンスターメソッドを変更する必要がありますが、テストを書くことができません；どうすれば何も壊していないことを確認できるでしょうか？；もうウンザリです。何も改善できません）；第３部　依存関係を排除する手法

フェザーズ，マイケル・Ｃ．(フェザーズ，マイケルＣ．)
Ｏｂｊｅｃｔ　Ｍｅｎｔｏｒ社勤務。現在、ＴＤＤ（テスト駆動開発）、リファクタリング、オブジェクト指向設計、Ｊａｖａ、Ｃ＃、Ｃ＋＋、ＸＰ（エクストリームプログラミング）に関するトレーニングやメンタリングを世界レベルで実践している。またＣｐｐＵｎｉｔ（ＪＵｎｉｔをＣ＋＋に移植したテスティングフレームワーク）、およびＦｉｔＣＰＰ（ＦＩＴをＣ＋＋に移植した統合テスティングフレームワーク）のオリジナル開発者でもある。ＡＣＭおよびＩＥＥＥ会員