レガシーコード改善ガイド読書メモ

電子書籍で買えばよかった・・・

1章　ソフトウェアの変更

ソフトウェア変更の4つの理由

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

4つの変更を加えると変化するもの

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

プログラムの振る舞いを保ったまま変更するときに考慮すべきこと

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

2章　フィードバックを得ながらの作業

システム変更の方法

• 編集して祈る
• 保護して変更する

後者がベストだがほとんど前者になっているのが現状

大規模テストによる問題点

• エラー箇所の特定が困難
• 実行時間が長くなる
• カバレッジの把握が困難、新規コード追加時に高いレベルのテストを書く必要があるので作業量が増える

優れた単体テストの条件

• 実行が速い
• 問題箇所の特定がし易い

実行に0.1秒もかかる単体テストは、遅い単体テストである。

• 10テスト/クラス×0.1秒×3000クラス=3000秒＝50分
• 10テスト/クラス×0.01秒×3000クラス=300秒＝5分

2~3時間ごとにすべてのテストを動かす場合を想定すると0.1秒だときつい。

単体テストと分けて考えるべきもの

1. データベースとやり取りする
2. ネットワークを介した通信をする
3. ファイルシステムにアクセスする
4. 実行するために特別な環境設定を必要とする（環境設定ファイルの編集など）

上記テストは価値があるが、単体テストとは分けて考える

レガシーコードのジレンマ

コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある。

レガシーコードの変更手順

1. 変更点を洗い出す
2. テストを書く場所を見つける
3. 依存関係を排除する
4. テストを書く
5. 変更とリファクタリングをおこなう

レガシーコード改善ガイド (Object Oriented SELECTION)