「リファクタリング　既存のコードを安全に改善する」を読む 2

その1

第２章

  • 機能追加とリファクタリング
    • 「重要なのは、どちらの帽子をかぶっているのか常に意識しておくことです」
    • 機能追加
    • リファクタリング -> 外から見た振る舞いを変えずに、内部を理解しやすく、変更しやすくする
      • 機能追加しない、テストは変えない
      • リファクタ前にテストが足りなければ足すけれども、リファクタリングで外から見た振る舞いは変わらないのだから、テストは変えなくていいはず
  • 「コードを理解しようとする時には、常にリファクタリングが役立ちます」
  • 間接層とリファクタリング
    • 「1つのものを2つに分割するということは、それだけ管理しなければならない部分が増えるということです。間接層は、最小限に絞り込むべきです。」
  • リファクタリングと設計（めっちゃいいこと言ってる、最高
    • 柔軟性を求めた設計は過度に複雑になりがちで、作りづらく、保守しにくく、苦労して作ったわりに使われなかったりと挫折感がある
    • リファクタリングを前提として設計すると「妥当な設計」でよくなる（「完璧な設計」じゃなくて良い
    • 柔軟な設計を作り込む代わりに「リファクタリングしやすいシンプルな設計」を考える（柔軟な設計より比較的簡単)
  • 特性の横恋慕
    • データと振る舞いを1つにまとめるのも重要だけど、振る舞いのみの変更に対処するために、データ/振る舞いの２つに分けた方がいいこともある。（ただし、回りくどくなるという欠点もある)
      • memo: 初めから2つに分ける派だけど、人に説明する時に便利そうな文だと思った

第４章

  • 単体テストと機能テスト
    • 単体テストはプログラマの生産性を向上するために行うものです。それで品質が上がるのは嬉しい副作用にすぎません。
    • 機能テストはソフトウェアの品質を保証するためのもので、プログラマの生産性とは無関係です。
    • 機能テストや実用でソフトウェアのバグが見つかったら、バグを明らかにするための単体テストを追加すべきです
  • 完全なテストを求めるのではなく、怪しいと思う部分をテストすること。
  • 多大な時間をかけて全てのバグを見つけるより、適切な時間で大部分のハグを見つけること

6〜11章

  • 特に目新しいのはなく「あるある〜」という感じだったけど、改めて「やっていいんだな」という許しを得られた
  • たまに「自分はやらん」というのもある
    • ポリモーフィズムによる条件分岐の置き換え(p255)、サブクラスの抽出(p330)
      • memo: まったくやらん訳では無いけどすぐ選ぶ選択肢でも無い。なぜなら私が継承の柔軟性を信用していないから
    • Template Methodの形成(p345)
      • memo: 継承前提の実装はTemplateの把握に苦しんだり、意図から外れた使い方されると途端に取り回しが困難になったりするので...
  • 苦肉の策よかった
    • 外部メソッドの導入([p162)
      • サービスクラスを拡張したいが許されない場合、サービスクラスのインスタンスを元に頑張る方法
    • 局所的拡張の導入(p164)
      • １クラスに対して「外部メソッドの導入」を複数大なう場合は、継承 or 移譲 を作る
  • データクラスによるレコードの置き換え(p217)
    • memo: データクラスよく使うんだけど、「データクラス = 振る舞いが無い、オブジェクト指向じゃない、やめるべき」みたいな風潮あるの？