レガシーコード改善ガイド（Micheal C. Feathers）

オススメ度★★★

レガシーコードからの脱却でリファレンスされている厳選された数冊に入っていたため、読んでみた。

既存システムへの機能追加をする際に参考なる実用的なアイデアが盛りだくさんで、非常に勉強になる。

また、リファクタリングをする前にテストを用意するフェーズでは、最適な設計を目指しすぎないことの重要性が何度も語られていた。テストを追加するために一旦改善の余地があるコードにしても気にしなくてよいとのこと。テストがあると、後でいくらでもリファクタリングできる。ついつい最適を求めて際限なくコードを修正しがちなので、教訓だと思う。

9章以降は25章にある手法が頻繁に参照されているため、先に25章を読んだ方がスムーズに読める気がする。

メモ

• 2章
  • 0.1sもかかるテストは単体テストではない
  • 3000クラスで10個ずつテストがあると、1時間かかる
• 5章
  • ツールによるリファクタリングでバグを埋め込む場合もある
    • 下記を確認すること
    • メソッド抽出時、同じクラスに元々存在するメソッドと同じ名前はエラーになるか？
    • メソッド抽出時、基底クラスのメソッドと同じ名前だったら検出されるか？
• 8章
  • テスト駆動開発
    • よく似た機能を追加する場合、一旦コピペして実装
    • その後、リファクタリングする
    • コードを書くか、リファクタリングするか、のどちらかだけを行うこと
• 11章
  • 変更箇所の影響先を分析し、末端でテスト・検証する
• 12章
  • 複数クラスをまとめてテストするのが有効な場合がある
  • 既存コードにテストを整備する場合
  • その後、リファクタリングするにつれてクラス毎のテストが増えていき、役目を終える(削除)
• 13章
  • 既存コードの動きを確認、保証するために仕様化テストを使う
• 16章
  • 捨てる前提で既存コードをリファクタリングし、コードの理解を深める（試行リファクタリング）
• 20章
  • テストしたくなるprivateメソッドは別クラスに切り出してpublicにすべきサインかも
• 23章
  • 一度に一つずつ修正してテストする
  • 一度にたくさん修正しようと色々試すのではなく、コードが何をしているかきちんと把握しながら慎重に作業する
• 25章
  • staticメソッド呼び出しをモックする
    • 呼び出しの抽出とオーバーライド
    • getメソッドの抽出とオーバーライド
  • サブクラス化とメソッドのオーバーライド
    • 新しいメソッドを抽出するより、既存メソッドを極力オーバーライドする
  • Java無関係
    • 定義の補完
    • 関数ポインタによる関数の置き換え
    • インスタンス変数の入れ替え
    • テンプレートのよる再定義
    • テキストによる再定義