リファクタリングという技法は，アジャイル開発のプラクティス（実践手法）のひとつとして発展してきた。しかし現在では，リファクタリングという言葉そのものは，「コードをきれいにする」という程度の一般的な意味で，ソフトウェア開発者なら聞いたこと，使ったことがある方が多いだろう（正確な定義は本文参照）。しかし，その意義・意味をどれだけ正確に理解していただいているだろうか。
　よくある誤解の1つめは，技法も作法もなく，プログラマー個人の勘と経験でコードをきれいにすることを，リファクタリングとよんでいる場合である。リファクタリングには，プログラミング初心者であっても，安全にコードをきれいにするためのテクニックと手順がきちんと存在する。
　もう1つ，よくある誤解としては，リファクタリングを非常に小さいレベルでコードをきれいにするためだけの手法だと思っている場合である。たとえばメソッド内の条件分岐の構造をわかりやすくしたり，変数名を変更したりすることである。
　これも，もちろんリファクタリングの一種であるが，リファクタリングにはもっとさまざまな粒度のものも含まれる。クラス内で別メソッドをつくる，クラス間でフィールドやメソッドを移動する，クラス間の継承関係を変更する，さらにはデザインパターンの適用もリファクタリングのひとつである。とくにアジャイル開発では進化的設計が基本であるため，開発途中でソフトウェアの全体構造を変更する「アーキテクチャリファクタリング」を行なうことさえある。
　逆に，大きなレベルでのソフトウェアの構造変化のみを，リファクタリングと考えている場合もある。さらにこの場合は，「リファクタリングツール」とよばれる魔法のようなツールがあって，それを使えば，現状スパゲティ状態になっている構造がすぐにきれいになると誤解している場合もある。たしかにリファクタリングツールとよばれるものは存在するが，それはそんな魔法の道具ではない。小さいレベルのリファクタリングを安全に行えるように考えられたツールである。
　重要なことは，そのような小さいレベルのリファクタリングを積み上げることによって，大きな粒度の構造変更が行なえるということである。アーキテクチャリファクタリングも，小さいリファクタリングを着実に積み上げることで，初めて実施できる。
　これに伴って，ぜひとも認識して頂きたいことは，「設計を具現化しているのはコードである」ということだ。当然だと思われる方は，それで構わない。しかし，とくにウォータフォール的な開発になじんでいる方の一部には，設計とはUML（Unified Modeling Language）などを使って図を描き，さらに各メソッドをどのようにプラグラムするかというプログラミング指示書を書くことであり，実装者（プログラマー）は単純にそれをコードに変換するだけだと考えている人がいる。
　もちろん，UMLでクラス図を描いたり，設計書を書いたりすることも，設計という行為の一部である。しかしその設計の実体はどこにあるかといえば，コードにある。UMLやドキュメントはあくまでもモデルであり実体ではない。これはコミュニケーションの手段としてUMLやドキュメントの必要性を否定しているのではない。チームで設計の議論をするためにUMLを使ったり，今後のメンテナンスのためにドキュメントを残したりする必要はあるだろう。しかし，それはあくまでもコードのなかにある設計を人間にとってわかりやすくするための手段であって，コードとドキュメントのあいだに差異があれば，違っているのはつねにドキュメントの方である。
　つまり，いくらきれいな設計図があったとしても，コードがそれを具現化していなければ，よい設計のソフトウェアとはいえない。そのようなよくない設計（コード）をきれいな設計（コード）にすることが，リファクタリングである。行なっていることの1つ1つは，既存のコードから新規にメソッドを抽出したり，あるフィールドを別のクラスに移動したりという，単純なことである。しかし，それによってソフトウェアがきちんとコンポーネント化されたり，アーキテクチャレイヤー間の依存関係が疎になるなど，ソフトウェアの大きな構造を変えていることを念頭に置く必要がある。
　リファクタリングといえば，原典はマーチン・ファウラー著『リファクタリング』である。この書籍の内容は現在でも陳腐化していないし，本書で同じ内容を繰り返す必要もない。原典は「カタログ」として手元に置いていただきつつ，そのカタログに掲載されているリファクタリングを組み合わせた比較的大きなレベルの設計の変更を行ない，リファクタリングの意義や進め方を理解していただこうというのが，本書の目的である。

2013年3月
著者しるす