リファクタリング（Refactoring）

リファクタリング（Refactoring）とは、プログラムの外から見た動きは変えずに、内部の書き方や構造を整理して、読みやすく直しやすい形に改善することです。機能を増やしたり不具合を直したりする作業とは区別され、将来の開発をしやすくするための手入れとして行われます。

現実世界に例えると、リファクタリングはお店の営業はそのまま続けながら、倉庫の棚を整理し直すことのようなものです。お客さんから見た品ぞろえは変わりませんが、どこに何があるかが分かりやすくなり、次の仕入れや品出しが格段に楽になります。

リファクタリング図解

※画像をクリックすると拡大表示します。

なぜ必要になるのか

背景にある事情です。プログラムは、機能の追加や急ぎの修正を重ねるうちに、継ぎはぎだらけで分かりにくい状態になっていきます。そのまま放っておくと、少しの変更にも時間がかかり、思わぬ不具合も起きやすくなります。こうした将来の負担は「技術的負債」と呼ばれ、リファクタリングはそれを返していく作業にあたります。

動きを変えないのが大原則

定義の核心です。リファクタリングでは、利用者から見た動作を一切変えないことが前提です。整理のついでに機能を追加したり、不具合を直したりすると、問題が起きたときに原因の切り分けが難しくなります。構造の整理と動作の変更は、別々の作業として分けて行うのが基本です。

代表的な手法

具体的な作業の例です。よく使われる手法には名前が付けられており、目的に応じて使い分けます。

テストが安全網になる

進めるための前提です。動きが変わっていないことを確かめるには、自動で実行できるテストを用意しておくことが欠かせません。手を入れるたびにテストを動かし、すべて成功すれば、少なくともテストで確かめている範囲では動作が保たれていると分かります。テストがないまま大きく書き換えるのは危険です。

小さな一歩を積み重ねる

進め方のこつです。一度に大きく書き換えるのではなく、名前を1つ変える、関数を1つ切り出すといった小さな変更を、確認しながら積み重ねていきます。途中でおかしくなっても、直前の状態にすぐ戻せるため、安全に進められます。小さな改善でも、続けるうちに全体の見通しは大きく変わります。

いつ行うのか

タイミングの考え方です。リファクタリングのためだけにまとまった期間を取るより、機能を追加する前や不具合を直す前に、関係する部分を少し整える形がよく勧められます。触る場所を、触る前より少しきれいにして去るという心がけで、無理なく継続できます。

作り直しとの違い

混同しやすい作業との区別です。リファクタリングは、今動いているプログラムを生かしたまま少しずつ改善するのに対し、作り直しは一から書き直すことを指します。作り直しは期間も危険も大きいため、まずはリファクタリングで改善できないかを検討するのが一般的です。

道具の支えもある

作業を助ける仕組みです。多くの開発環境には、名前の変更や関数の抽出を、関係する箇所すべてに自動で反映させる機能が備わっています。手作業で置き換えるより漏れや誤りが少なく、安心して整理を進められます。最近では、AIに改善の案を出してもらう使い方も広がっています。

あわせて知っておきたい用語

• 技術的負債：
  その場しのぎの作りが、将来の開発の負担として積み重なることです。
• 単体テスト：
  プログラムを小さな部品ごとに動かして確かめるテストです。
• コードレビュー：
  書いたプログラムをほかの人が読み、問題がないかを確かめることです。
• デグレ：
  修正によって、以前は正しく動いていた機能が壊れてしまうことです。