リファクタリングとは、ブラウザなどの外部から見た時のふるまいを変えることなく、プログラムの内部構造を整理するソフトウェア開発で行う作業の一つです。

ここ数年、「システムの不具合を改修したい」「度重なる開発者の退職で、ソースコードが複雑で機能追加ができない」「メンテナンスができない」「ミドルウエアのバージョンアップができな」といった悩みを聞く機会が多くなってきました。

リファクタリング(Refactoring)という言葉がよくわからないのだけど、「ソースコードの最適化」や「バグの改修」ができないかとご相談を頂く機会が増えてきましたので、今回は、改めてリファクタリングとは具体的にどのようなことを行うのか？についてまとめてみました。

リファクタリングとは？

冒頭でもご説明しましたが、リファクタリングとは、ブラウザなどの外部から見た時のふるまいを変えることなく、プログラムの内部構造を整理するソフトウェア開発で行う作業の一つです。

リファクタリングという言葉を大きく広めたのは、米国のMartin Fowler（マーチンファウラー）先生の「ファクタリング : プログラミングの体質改善テクニック」という本ででした。私自身が、ソフトウェアエンジニアとしてのキャリアを歩みだしたころ、先輩のススメで読んだのがこの本を最初に手にしたように記憶しています。

当時は、「実装した後に、設計をする」という感覚や、コードの匂いという部分に”はてなマーク”がつきながら、とにかく1回読んだのを記憶しています。

この初版本の出版から約18年以上の時が経過しましたが、現在もリファクリングという言葉は、エンジニアの中で使わない人はいなぐらい利用されていると感じています。ソフトウェア業界の中で、10年以上話題に上がり続けるのは、珍しいのですが、それだけシステム開発やシステムの運用に必要不可欠な技術だと感じています。

挙動に問題がなくても、内部のコードが最適な状態とは限らない

ソフトウエアとは外部からの見た目や挙動に問題がなくても、内部のコードが最適な状態とは限らないのがソフトウエアというものです。無駄なコードが多く、分かりにくい構造になっていることがありますし、セキュリティ脆弱性となっているバグが潜んでいる可能性もあります。

この状態は、長く保守運用しているコードにはありがちなことですが、リファクタリングでは、このようなコードを整理して洗練された状態に変更していくことを行います。

よく誤解されるのですが、機能追加やバグの改修は、厳密な意味でのリファクタリングではありません。外部からみたときのソフトウェアの挙動を変更してしまうからリファクタリングとは呼ばないというのが開発者的な見解となりますが、多くのリファクタリングプロジェクトでは、新機能の追加開発やバグの改修をプロジェクトの中で実施しながら、リファクタリングを行うことが一般的になっています。

似たような言葉にプログラムのパフォーマンス・チューニングという言葉があります。こちらは、外部的な振る舞いを変更することなくプログラムの速度を向上するような取り組みをすることです。一般的にパフォーマンス・チューニングをするとコードは読みにくくなります。リファクタリングは、コードを読みやすくする対応をする中でパフォーマンスを犠牲にするということも厭わない変更をします。リファクタリングよりもパフォーマンスが重要である場合は、コードが扱いにくくなることを厭わない変更も許容すべきと考えています。

リファクタリングを行う目的とは？

普段、開発者がやっている作業は、コードを書くことよりもコードを読む時間の方が圧倒的に多く、簡単な機能追加やバグだと思っていたのに、いつまでたっても完了しないということが度々発生します。

その原因は、ソースコードが不必要に長く、コピペや不要な処理が永遠と書き綴られているコードが大量にあることにあるのですが、リファクタリングを実施することによって、開発者が普段当たり前に行っているコードを読む時間そのものを減らし、開発の効率を向上させる効果が生み出すこともリファクタリングの大きな目的となっています。

リファクタリングでは、具体的に何を行うのか？

テストコードがない場合にも必ずここから始めます。リファクタリングの前提は、リファクタリング前後で”挙動を変えない”ことです。レガシーコードなどでは、テスト方法が確立していないケースがありますので、まずは、既存のコードの挙動を把握するためにも、テストできるようにしましょう。

• まとまった処理をメソッドとして重複部分を減らす
  コードは重複部分が多いと読みにくくなります。また、ロジック変更時には重複部分がすべて対象になるため負担が大きくなります。分岐条件が追加される際は、各ケースに重複部分があれば、さらに重複部分が増えてしまいます。
• ネスト（入れ子）を浅くする
  ネストが深いと条件が分かりづらく、テスト時に漏れが生じるかもしれません。条件の順番を入れ替える、一部をメソッドとして抽出するなどしてネストを浅くしましょう。
• 変数や関数の名称をシンプルにする
  名称が内容を簡潔に表現できていれば理解が円滑化します。他者に誤解される名称は避けましょう。また、これらの作業を円滑化するにはツールの利用が有効です。リファクタリングをサポートする機能が備わった開発ツールを使えば、リファクタリングの手間と人為的ミスを減らせます。

リファクタリングの注意点

前述しましたが、普段、開発者がやっている作業は、コードを書くことよりもコードを読む時間の方が圧倒的に多いです。簡単な機能追加やバグだと思っていたのに、いつまでたっても完了しないってことは、結構あると思います。そのようなことを減らすのにもリファクタリングは有効なのです。

やりがちなことですが、リファクタリングの前提は、リファクタリング前後で”挙動を変えない”ことですので、そこは分けて作業しましょう。バージョン管理ツールなどをうまく使って、リファクタリング中は、リファクタリングに専念することが重要です。これを守らないと十中八九失敗します。ちなみに、「テスト駆動開発」で有名なKent Beck氏は、これを２つの帽子というような表現を用いて説明しています。

リファクタリングは前後でソフトウェアの挙動が変わってはいけません。そのため、リファクタリング後には必ずテストし、挙動が変わっていないことを確認する必要があります。そのため、リファクタリングの作業は細かく分割して行うことが推奨されています。広範囲にわたるコードを一息にリファクタリングし、テストにパスできなくなると、どこに問題が生じたのか分かりづらいためです。

---

ここまで”リファクタリングの基本的なご紹介”から、”リファクタリングを行う目的”、”リファクタリングの注意点な”どについてご紹介してきました。次回は、リファクタリングを行った過去の事例なども交え、リファクタリングに着手する時期などについてご紹介できればと思います。