機能を変えずに構造を変える：Martin Fowler『リファクタリング』第2版

「リファクタリング」という言葉は広く使われるが、その定義はあいまいに使われることも多い。Martin Fowler の『リファクタリング 既存のコードを安全に改善する 第2版』は、この行為を厳密に定義し直し、実践可能な技法として体系化した一冊だ。

1. リファクタリングの定義——「改善」ではなく「変換」

本書の定義は明確だ。リファクタリングとは「外部から見た振る舞いを変えずに、内部の構造を改善すること」だ。

この定義が重要なのは、外部の振る舞いが変わるなら、それはリファクタリングではなく機能変更だからだ。両者を同時に行うと、どちらの変更が原因でテストが壊れたか判別できなくなる。本書が推奨するのは「リファクタリングのステップ」と「機能追加のステップ」を意図的に分けることだ。

この区別は、コードレビューやコミット履歴の粒度にも影響する。

2. コードの匂いとリファクタリングの契機

本書の約半分は「コードの匂い（Code Smells）」と各リファクタリング手法のカタログで構成されている。

代表的な匂いとして挙げられるのは、「長い関数」「巨大なクラス」「重複したコード」「長すぎるパラメータリスト」「データの浮遊（Data Clumps）」などだ。これらは直ちに問題が起きているわけではないが、変更に弱い設計のシグナルだ。

匂いを検出したら、対応する手法（例：長い関数 → 関数の抽出）を適用する。この「匂い→手法」の対応関係が整理されているため、感覚的だったリファクタリングの判断を具体的な手順に変換できる。

3. テストなしのリファクタリングは進めない

本書が一貫して強調するのは、テストがリファクタリングの安全網であるという点だ。

外部の振る舞いが変わっていないことを確認できなければ、リファクタリングが「改善」なのか「壊した」のかが分からない。自動テストが通る状態を保ちながら、小さなステップでコードを変換していく——これが安全なリファクタリングの進め方だ。

逆に言えば、テストが書きにくいコードはリファクタリングもしにくい。テストを書くことが難しいと感じたら、それは設計の問題を示すシグナルでもある。

4. リファクタリングと設計判断

本書が示す重要な観点の一つが、リファクタリングと事前設計の関係だ。

詳細な事前設計よりも、動く小さな実装から始めてリファクタリングで洗練させる方が、実際には良い設計に到達しやすい場合がある。設計は一度決めたら変えられないものではなく、コードが成長する中で継続的に改善するものだという見方は、アジャイルな開発スタイルとも整合する。

本書の第2版はJavaScript（TypeScript）のコード例を多く使っており、フロントエンドを含む現代の開発環境で読みやすくなっている。

DevBookPath のマップで確認する

この本の前後の読書順は、DevBookPath のグラフで確認できます。

👉 ソフトウェア設計の地図を見る

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。