リファクタリングは、プログラムの外から見た動作は変えずに、内部のコード構造を改善する 作業です。
Martin Fowler の書籍 Refactoring: Improving the Design of Existing Code (1999) で広く知られるようになり、現代の開発現場では当たり前の用語になっています。
まず押さえたいポイント
- 機能追加と同時にはやらない。振る舞いを変えない のが定義
- 小さなステップを積み重ねる。
変数名を直す関数を抽出するクラスを分けるレベルから - テストが揃っていることが前提。テストが無いと「変えてないつもり」 が「壊した」 になる
- 目的は 将来の変更コストを下げる ことであって、見た目を綺麗にすることではない
代表的なテクニック
Martin Fowler の書籍ではリファクタリング手法がカタログ化されています。よく使うものを挙げると:
Extract Function— 長い処理を関数に切り出すRename Variable— 名前を意図が分かるものに変えるInline Variable— 不要な中間変数を消すReplace Conditional with Polymorphism—ifの塊をポリモーフィズムで置き換えるMove Method— メソッドを適切なクラスに移動Extract Class— 大きすぎるクラスを分割
IDE (IntelliJ / VS Code / JetBrains 系) には、これらを安全に実行する Refactor メニューが用意されています。
いつやるか
Boy Scout Rule— 触ったファイルを少しだけ綺麗にして帰る、というルールバグ修正の前— 直す前に整理してから直すと、原因が見えやすい機能追加の前— 拡張ポイントを作るためにリファクタリングして、その後で機能を足す
いったん全部書き直す は リライト であってリファクタリングではありません。大規模リライトは失敗確率が高く、Joel Spolsky の有名なエッセイ Things You Should Never Do, Part I でも警告されています。
リファクタリングと AI
2026 年現在、AI コーディング環境 (Claude Code など) は変数のリネーム、関数抽出、デザインパターンの適用などのリファクタリングを高速に提案できます。
ただし 振る舞いを変えない 保証は AI には難しいため、テストが先にある 状態でないと、AI のリファクタリング提案を受け入れるのは危険です。
よくある誤解
リファクタリングは 機能追加と一緒にやる ものではありません。
混ぜると この変更は機能追加なのか整理なのか がレビューで見えなくなり、バグが入り込む確率が上がります。リファクタコミット と 機能追加コミット を分けるのが基本です。
詳しくは AI でレガシー保守を加速する と 枯れた技術を選ぶ価値 で、レガシーコードのリファクタリングと AI 活用のパターンを整理しています。