Chapter2: Working with Feedback フィードバックを利用する

WEwLC

Working Effectively with Legacy Code 読書メモ

  • Chapter2: Working with Feedback フィードバックを利用する
    • システム変更には２つの流儀。
      • Edit and Pray (編集して祈る)は業界標準。変更を綿密に計画して作業にあたる。変更後は正しく動くことを期待する。本当にうまくいったかどうかはあとで分かる。
      • もう一つの方法はCover and Modify (カバーと修正)。変更をセーフティネット(テスト)で守る。 よいテストセットがあれば、変更結果の善し悪しがすぐに判る。
    • 変化を検知するリグレッションテスト。アプリケーションレベルでテストする。Web/CUI/GUI どれもいける。よくあるケースは夜間に回す。しかしテスト結果を受け取るのが翌朝。それって誰がいじったコード？
    • ユニットテストならば１分で結果がでる。だから、リファクタリングがもっと安全になる。
    • ユニットテストの長所は３つ。
      • エラー箇所の特定がしやすい
      • 実行時間が短い
      • カバレッジ
    • ユニットテストは、もっと大きな粒度のテストと補完関係にある。
    • ユニットテストで、0.1秒以上かかるテストはスローなテスト。3000個のメソッドに10個ずつテストを書いて、総数30000件とかあったら回らない。
    • データベースと繋ぐ、ネット越しアクセス、ファイルアクセス、環境依存、を含むものはマスカレード（偽装）してユニットテスト中には動かないようにするよろし。
    • レガシーコードのジレンマ: コードを変更するならテストを入れるべき。でもテストを入れるために、コードの変更が必要なことがある。
    • レガシーコード変更
      • 1.変更点を明らかにする。
      • 2.テスト点を見つける。
      • 3.依存性を断つ。
      • 4.テストを書く。
      • 5.変更とリファクタリング