プレファクタリング ―リファクタリング軽減のための新設計 (THEORY/IN/PRACTICE)
- 作者: Ken Pugh,木下哲也,有限会社福龍興業
- 出版社/メーカー: オライリージャパン
- 発売日: 2006/01/16
- メディア: 大型本
- 購入: 3人 クリック: 60回
- この商品を含むブログ (32件) を見る
リファクタリングの考えや手法を設計段階(それ以前も)から適用して、その後のリファクタリング効率をあげましょう、という話と理解。
そのための指針がちりばめられている本です。
以下、備忘録として抜粋。いつか自分の言葉として語れるようになりたい。
- わざわざ1から作り直さない
- 新しい解決策を作成する前に、問題に対する既存の解決策を探します。
- 全体像を考える
- システムにおける判断は、全体像と合致すべきです。
- 大局的に計画し、局所的に開発する
- 実装を追加していく場合は、大局的な計画に適合すべきです。
- 抽象化する際には、全てに対して抽象化する
- 基本データ型を使ってデータ項目を表してはいけません。
- ほとんどのStringは、単なるString以上のものである
- Stringを基本データ型として扱います。属性は、Stringではなく抽象データ型(ADT)で記述します。
- テキストにすべきか否か
- テキストは、プログラム内ではなくプログラム間で使用します。
- クラスへのメソッドの配置は、メソッドが何を必要としているかに基づいて行う
- メソッドがインスタンスデータを必要としていなければ、そのメソッドはそのクラスのメンバにすべきではありません。逆に、メソッドの必要とするものがインスタンスデータだけであれば、そのメソッドはそのクラスのメンバにすべきです。
- ポリシーと実装を分離する
- 実行することとその方法を分離するようにすると、実行することが読みやすく、保守しやすくなります。
- 関心事を分離して、関心事を小さくする
- 複数のメソッドと複数のクラスに責務を分割して、各メソッドとクラスを簡潔にします。
- インターフェースを分割する
- 複数のクライアントが1つのインターフェースの異なる部分を使っている場合、そのインターフェースを複数のインターフェースに分割します。
- バラ以外の名前がついたバラは、バラではない
- システムの各概念に対して、明確に定義された名前を作成します。
- テストできないものを必要としてはいけない
- 公式に述べられていようと、非公式に述べられていようと、全ての機能要件には、その機能用に作成されたテストを持つべきです。要件をテストできなければ、その要件を満たしているか判断する方法はありません。
