「リファクタリング」の完全読破。その1

ファウラーの言わずと知れた名著だけど、私は15章構成のうちカタログ部分（第5章〜第12章）を今まで読んでいなかった。
理由としては、やはり古いこと、そんなに難しい内容では無いこと、リファクタリングの思想という意味では理解していたこと。

ホントに古い本なので、もういいかなと思っていたんだけど、少し読み直したらやっぱり一度は全部書くべきだった。
リファクタリングの思想と同じくらい、カタログにある各種技術は重要だった。
それに「おすすめの本は？」と聞かれたときに、とりあえずこれを挙げることは多くて、そのくせ完読してないのは質が悪いというのもある。

ということで、今回は「はじめに」と「第1章」

はじめに

ここでは本書の説明と、リファクタリングについての話が少し。
・リファクタリングはリスクが高いのでやみくもに行ってはいけないこと。
・手順を守り、体系的に行うこと。
・具体的には「1度に1ステップずつ」行うこと。
それに、ファウラーとKent Beckが以前にした仕事の話がある。さらっと読む。

第1章　リファクタリングー最初の例

大まかには、3つのクラスからなるシステムをリファクタリングしていくという流れ。
最初の状態では、class Customerが、巨大なstatement()メソッドを持っており、明らかに悪い設計となっている。

まずは、Eclipseを起動してこの悪いコードを書き、本書の通りにリファクタリングをしていく。
内容は「1度に1ステップずつ」の思想を守っているので、非常に簡単。
頭を使うのは最後のポリモーフィズムだけ。

まず最初にテストの重要さが書かれる。

（P7~8）
最初にすることは常に同じです。対象となるコードについてきちんとしたテスト群を作りあげることです。
リファクタリングの成功は、良いテストを用意できるかで決まります。

とあるが、本書にはテストコードはないので、JUnitを使って自分で書く。
そしてリファクタリングをはじめる。
ほとんどが基本的なことだけど、改めて読むと勉強になる。

メソッドの抽出(P110)

switch文をメソッドにする。
ローカルなスコープを持つ変数は、新規メソッドの引数か一時変数にならないか検討する。変更されない変数はメソッドの引数として渡すことができる。

変数名を変更する

コンパイラが理解できるだけではなく、人間にとって解りやすいコードにする。

メソッドの移動(P142)

使用するデータを持つオブジェクトにメソッドは定義されるべき。

問い合わせによる一時変数の置き換え(P120)

代入した後に変更されない一時変数は、問い合わせメソッドにする。
一時変数は長くて複雑なルーチンの原因となるので、できるだけ減らす。
thisAmountやtotalAmountのようなそれっぽい変数があやしい。

P34　料金計算の条件文をポリモーフィズムに置き換える

ここだけ、ちょっと大きい。
「他のオブジェクトの属性を調べるswitch文を書くことは、常に間違いです。他のオブジェクトではなく自分自身について行うべきなのです。」
とあり、それを実現する。そのために以下の手順が必要。

State/Strategyによるタイプコードの置き換え(P227)
自己カプセル化フィールド(P171)
メソッドの移動(P142)
ポリモーフィズムによる条件記述の置き換え(P225)

まとめ

P52
（リファクタリングは）クラスの責任を分割させ、保守しやすいコードを書くのに役立ちます。
手続き的なコードとはかなり様子が異なるので、慣れるのには時間がかかるかもしれません。
しかし、いったん慣れてしまえば、もう手続き的プログラミングには戻れないものです。

「はじめに」でファウラーが言及したプロジェクトも汚いコードだったらしい。
その例も含め、リファクタリングの工数を見積もれるプロジェクトというのはほとんど無い。
本書を読んでもその事実は変わらず、これを読んだからって工数がもらえるわけではない。

ただ、そんな中でも本書のカタログにある技術を習得するのは大事。リファクタリング云々の前に、コードの質が良くなる。
ホントに古い本なので「今風の書き方」という意味では参考にならないけど、技術としてはその一歩手前の「設計」が学べる。
例えば上記の引用の通り「Javaで書いた手続き型のコード」があったら、それをスマートに修正できるようになる。

並行で他にもいろいろと読んでいるけど、8月中には「リファクタリング」を終えたい。