リファクタリングとは
リファクタリング（Refactoring）は、プログラムの「外側から見た動作（仕様や挙動）」は一切変えずに、プログラムの「内側の構造（コードの綺麗さや整理状況）」を整理して、読みやすく・修正しやすく改善する作業のことです。ソフトウェアは機能追加を繰り返すとソースコードが複雑になり（スパゲッティコード）、バグが発生しやすくなったり開発効率が落ちたりします。定期的にリファクタリングを行うことで、コードの健全性を保ち、将来の機能追加や変更に耐えられるシステムを維持できます。
具体例
例えば、同じ計算処理や画面表示のコードがプログラム内のあちこちにコピー＆ペーストされているとします。これを「共通の関数（メソッド）」として1か所にまとめ、それぞれの場所からその関数を呼び出すように書き換えます。画面上の動きは変わりませんが、コード量が減り、仕様変更の際も1か所直すだけで済むようになります。
【リファクタリングの例】\n[ビフォー（重複が多い）]\n・A画面: 税込み価格 = 金額 * 1.1;\n・B画面: 税込み価格 = 金額 * 1.1;\n\n[アフター（共通化）]\n・消費税計算関数: getTax(金額) { return 金額 * 1.1; }\n・A画面: getTax(金額);\n・B画面: getTax(金額);もう少し詳しく
リファクタリングを安全に行うための大前提は、「十分な自動テスト（ユニットテストなど）」が存在することです。テストがない状態でコードを書き換えることは、仕様を意図せず崩してしまう（デグレを発生させる）リスクが極めて高く、単なる「あぶなっかしいコード改変」になってしまいます。リファクタリングでは、コードの悪さを示す「コードの不吉な匂い（Code Smells）」を検出し、それを定型的な修正パターン（カタログ）を用いて排除します。代表的な不吉な匂いとリファクタリング手法には、以下のようなものがあります。・重複したコード ➔ 「メソッドの抽出」を用いて共通化する。・巨大なクラスや長すぎるメソッド ➔ 責務ごとに「クラスの抽出」や「メソッドの分割」を行う。・意味の分からないマジックナンバー ➔ 「シンボリック定数の導入」により定数に明確な名前を与える。これらを一度に全て行うのではなく、小刻みにコードを書き換えては自動テストを実行し、常に「動く状態」を維持しながらリファクタリングを進めることが技術的なルールです。
試験でのポイント
応用情報技術者試験では、システム開発手法やソフトウェア保守の文脈でリファクタリングの「定義」と「目的」が問われます。試験対策のポイントは、「外部から見たソフトウェアの仕様・振る舞い（外部仕様）を変更しないこと」および「ソースコードの保守性や理解のしやすさを向上させるために内部構造を改善すること」の2つの条件を同時に満たす選択肢を選ぶことです。「機能追加やバグ修正はリファクタリングには含まれない」という点は非常によく問われるため、明確に区別してください。また、リファクタリングを行う前提として「既存の動作を保証するためのテストケース（自動テストコード）が不可欠である」ことや、「リファクタリングによって将来の開発効率向上や不具合混入率の低下（技術負債の返済）が期待できる」という長期的なメリットを正しく把握しておく必要があります。
関連する用語
テストを先に書きながら実装と整理を進めるテスト駆動開発（TDD）、ソースコードの保守性を高めるために返済すべき開発コストである技術負債、および既存動作に問題がないか確認する回帰テスト（レグレッションテスト）があります。これらとリファクタリングの密接な関係性を整理することが大切です。