レガシーコード改善ガイド1章

ソフトウェア変更

要件の追加とバグの修正

バグ修正・要件追加など、色々な見方があるが、技術的に大切なことは、振る舞いが変更されるかどうかです。新しい振る舞いの追加と既存の振る舞いの変更には大きな違いがあります。

ソフトウェアで一番大切なことは、「振る舞い」であり、 ユーザーから見えるものは、振る舞いである。 期待される振る舞いを私たちが追加すれば、ユーザーは喜ぶが、ユーザーの求める振る舞いを変更、あるいは削除してしまえば、バグの作り込みとなり、私たちへの信頼は失われてしまう

振る舞いを追加するのか、振る舞いを変更するのか？という議論は問題点が明確に区別されにくい。これを区別する有効な方法をかんがえてみる

・新しいコードを追加してそれを呼び出すのみ　⇒ 振る舞いの追加
・既存のコードを変更する必要がある　　　　　⇒ 振る舞いの変更

設計の改善

リファクタリングでは、小さな構造修正を繰り返し行う

設計の改善は、別の種類のソフトウェア変更である。保守しやすくなるようにソフトウェアの構造を変更するとき通常は振る舞いを同じに保つ必要があります。多くの場合、設計を改善したがらないのは、その過程で振る舞いを失ってしまったり、間違った振る舞いを作りあげてしまいやすいからである。もし設計の改善の過程で必要な振る舞いが失われてしまえば、それはバグになってしまう。

設計の改善とはいわゆるリファクタリングというが、それは既存の振る舞いを壊さないように、テストを書き、小さな
ステップと検証を繰り返しながら行う必要がある。

リソース利用の最適化

最適化などによって、プログラムが使用しているなんらかのリソース（時間やメモリ）に相当する

プログラム変更のまとめ

どうすれば残りの振る舞いを変えずに済ませることができるかという問題を解決することができるかとう問題を解決する必要がある。

厄介なことに、コードに触っていなくても、振る舞いが変更されないという保証はありません。振るまいの変更によって保つべき振る舞いは大量にあります。それ自体は大きな問題ではありません。大きな問題は振る舞いの変更によってどれだけ振る舞いに影響が及ぶのか把握することが難しいことである。
変更を安全に行うために最も重要なことは、影響範囲を理解することです。

既存の振る舞いを変えずに保つことは、ソフトウェア開発で最も困難なことの一つである。主要な機能の変更するときでさえ、通常は既存の振る舞いの大部分を変更せずに保たなければならない

危険な変更

変更を行いながら振る舞いを維持する作業は大きなリスクをともないます。変更時は以下の３つを意識してください

1.どんな変更を行わなければならないか
2.変更が正しく行われたことをどうすれば、確認できるか
3.何も壊していないことをどうすれば確認できるか

変更のリスクを最小限に収めるために、変更を最小限に抑えるという考え方は、魅力的な考え方ですが、残念なことに必ず問題はつきまとってきます。新しいメソッドやクラスを作らないことには、既存のクラスやメソッドは、肥大化し、理解しづらくなります。

また、変更を避ける期間が長くなれば長くなるほどクラスを分割する作業は困難になる。また、日に日にチームが持つ変更に対する恐怖は強くなっていく。

変更をするのは大きなリスクを伴いますが、闇雲に変更を避けるのも優れた方法ではありません。