レガシーコード改善ガイド 第一章

変更する理由

1. 要件の追加
2. バグの修正
3. 設計の改善
4. リソース利用の最適化

要件の追加とバグの修正

問題なのは振る舞いが変更されるかどうかということ。

• 振る舞いの追加　→　既存の振る舞いに変更はなくバグは発生しない
• 振る舞いの変更　→　既存の振る舞いに変更があり、バグが発生する可能性がある

設計の改善

みんな設計を改善したいと思っていてもなかなかできないのは、それを行う過程で振る舞いが変わってしまったりしてバグを作ってしまうことになるから。

リファクタリングの作業の定石として、以下の手順がある。

1. 振る舞いが変更されていない事を保証するテストを書く
2. リファクタリングを行う
3. テストを実行してパスすることを確認する

リファクタリングは小さな構造修正を行う。一気に行わない。機能を変更すべきではない。

※ ただ全ての振る舞いを1でテストできているか把握するのが難しい

変更のまとめ

システムの変更作業を行った時に変わる可能性があるのは、「構造」「機能」「リソース利用」の３つ。

	要件追加	バグ修正	リファクタリング	最適化
構造	変化する	変化する	変化する	-
新機能	変化する	-	-	-
機能	-	変化する	-	-
リソース利用	-	-	-	変化する

（既存）機能が変化するのはバグ修正のみで、バグ修正でも変更されない既存機能に比べると変更される機能はわずか。

変更理由ごとに変更箇所をまとめることのメリット

良い点

• 何に集中すべきなのかがわかる

解決できていない点

• 集中すべきは変更箇所だけでなく、どうすれば残りの振る舞いを変えずに済ませることができるかという問題を解決する必要がある

変更を安全に行うために最も重要なことは影響範囲を理解すること。

危険な変更

変更を行いながら振る舞いを保つのは非常に困難、リスクを伴う
リスクを緩和するために次の３点を考慮する必要がある

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

しかし、すべての作業をやり終えた後で、その変更が正しいこと、既存の振る舞いを壊していないことを判断できる人などいるのか？