リファクタリング

リファクタリングとは「外部から観測できるふるまいを変えることなく、コードの内部構造を改善する」行為だ。Martin Fowlerが定義したこの概念は、機能追加やバグ修正とは明確に区別される。リファクタリングをする間はバグを直さず、バグを直している間はリファクタリングをしない。この原則を守ることで、変更の目的が明確になりレビューも容易になる。

リファクタリングを安全に行うための前提条件はテストだ。テストが存在しない状態でコードを動かし続けることは、綱渡りを目隠しで行うに等しい。レガシーコードにリファクタリングを施す際はまず「特性テスト（Characterization Test）」を書き、現在のふるまいを固定してから変更を加える。テストがあることで、小さなステップで安全に変換を進められる。

代表的なリファクタリング手法にはExtract Method（長い関数の一部を別関数に抽出）、Rename（命名の改善）、Move Method/Field（責務に合ったクラスへの移動）、Replace Temp with Query（一時変数をメソッド呼び出しに置き換え）などがある。コードの臭い（Code Smells）はリファクタリングの必要性を示すシグナルであり、重複コード・長すぎるメソッド・大きすぎるクラス・過剰なコメントなどが代表例だ。

コードレビューで着目するポイント

機能変更とリファクタリングが一つのコミットに混在していないか
リファクタリング前後でテストカバレッジが保たれているか
Extract Methodの結果、新しい関数名が意図を正確に表現しているか
重複したロジックが適切に一箇所に集約されているか
リファクタリングによってクラスや関数の責務がより明確になっているか
変数や関数の名前が改善後のコードの意図に合致しているか
一時変数の排除によって可読性が上がっているか（Replace Temp with Query）

典型的なアンチパターン

リファクタリングとデバッグの混在: 「ちょっと直しながらきれいにしよう」という意図でバグ修正とリファクタリングを同時に進める。原因究明が困難になり、レビュー時に意図が読み取れない変更が増える。

テストなしのリファクタリング: カバレッジが低い状態でExtract Methodを繰り返し、気づかずにロジックを変えてしまう。テストがないため回帰が検出されず、本番障害として表面化する。

過度なDRY化: 偶然似ているだけの2つのロジックを無理に共通化する。後から片方の仕様が変わったとき、共通化された部分に条件分岐が増え、元の重複コードより複雑になる。

参考リソース

Martin Fowler『Refactoring: Improving the Design of Existing Code』第2版（Addison-Wesley、2018）
Michael Feathers『Working Effectively with Legacy Code』（Prentice Hall、2004）
Refactoring.com — オンラインカタログ https://refactoring.com
JetBrains IDE（IntelliJ IDEA・WebStorm）— 自動リファクタリング機能が充実
Kent Beck『Test-Driven Development: By Example』（Addison-Wesley、2002）