リファクタリング-プログラムの体質改善テクニックの読書メモ

前回に登場したリファクタリングについてのメモ書きを今度は公開してみる。ただ、リーダブルコードと違ってこちらは少々厚めであるため、興味がある箇所をつまみ食いしながら読んだ方が多分長続きするだろう。リファレンス的にも使える本である。

なお、ここで上げたテクニックはほんの一例に過ぎないので注意。本には不吉な匂いに対する処方箋が数多くのっているので興味があるならば読んでみるのがオススメ。特にポリモフィズムを用いてSwitch文を無くしていく様には感動してしまった。

リファクタリングとは何か？

ソフトウェアの外部的な振る舞いを保ったままで、内部の構造を改造していく作業のこと。振る舞いを保っていることを保証するためには自動実行可能なテストが必須（Javaの場合はJUnitのテストコード）。

基本的には以下の作業を行なっていく。

• 属性をあるクラスから別のクラスへ移す
• メソッドの一部を抜き出して新たなメソッドを作る
• コードの継承階層の上下に移動する
• 条件分岐をポリモーフィズムで表現する

リファクタリングの原則

• リファクタリングは一時期にやるものではなく、チョコっとずつやる
• 機能追加とリファクタリングは同時には行わない　それぞれ専念して行う
• リファクタリングは原則として、テスト用のコードは弄らない
• 無い場合は先に作る
• ３度同じことをしているなと思ったらリファクタリングを試みる
• 機能追加時にリファクタリングを試みる
• リファクタリングで機能を理解するという面もある
• バグフィックス時にリファクタリングを試みる

リファクタリングを適用するタイミング

不吉な匂いを嗅ぎとったらやってみる。

• 長すぎるメソッド
• 巨大なクラス
• インスタンス変数の持ち過ぎ→責任の持ちすぎ
• 重複したコード
• 同じようなコードが2箇所以上で見られる
• 同一クラス内の複数メソッドに同じ式がある
• 同じアルゴリズムなのに実装が異なる
• 多すぎる引数
• 変更の発散
• 一つのクラスがお互いに独立した理由で同じように変更され、その手順も異なる場合に起きる
• 金融商品を追加するたびに４つのメソッドの修正がある、等
• 変更の分散
• 変更を行うたびにあちこちのクラスが少しづつ書き換わるような状態
• 属性、操作の横恋慕
• 自分のクラスの属性よりも他のクラスに興味を持っている
• データの群れ
• 複数個のデータがグループで様々な場所に登場する
• 基本データ型への執着
• 小さなオブジェクトを作るのを嫌がり、基本データ型に固執する
• スイッチ文
• 重複したコードを生み出す問題児
• パラレル継承
• 新たなサブクラスを定義するたびに、別の継承木にもサブクラスを定義しなければならない
• 疑わしき一般化
• 大した働きの感じられない抽象クラス
• 相続拒否
• 親クラスのものをほとんど必要としない
• コメント
• コメントの必要性を感じた時はリファクタリングを行ってコメントを書かなくと内容がわかるようなコードを目指すこと

基本のリファクタリングテクニック

リファクタリングのテクニックの基本は適切な固まりの単位で再構築することにある。

• メソッドの構成
• メソッドを適切にパッケージ化されたコードとして構成することが大切
• メソッドの抽出
• メソッド名が重要
• メソッドの名とメソッド本体の間の意味的な距離が重要
• メソッド名には内部でどのような処理をしているかではなく、そのコードは何をするのかという意図を示す
• オブジェクト間での特性の移動
• オブジェクトの設計において根幹をなすのは、責任を何処に配置するかについての判断
• メソッドの移動
• あるメソッドが定義されているオブジェクトよりもそれ以外のオブジェクトを参照することの多いメソッドを候補として考えてみる
• フィールドの移動
• クラスの抽出
• クラスのインライン化(クラスを廃止しコードに展開)
• メソッド呼び出しの単純化
• 最も重要なのはインタフェース。名前こそが重要。
• 引数の変わりにオブジェクトそのものの受け渡し
• 引数オブジェクトの導入
• コメントの使い方
• 不明点を書き留めておく
• よくわからない事項のメモを書き、「なぜ」このような処理を選択したのかを書いておく

参考文献

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)