リファクタリングってなんだろう

はじめに

リファクタリングをやることになったが、どのようなアプローチを取るのかわからなかったためざっくりとリファクタリングについて調べたことをまとめました。
実際のやり方というより、リファクタリングとはなんぞやという部分に焦点を当てているので、方法を知りたい場合はこの記事は適していません。

リファクタリングとは

書籍、リファクタリング 既存のコードを安全に改善する には次のように述べられています。

外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること
リファクタリング 既存のコードを安全に改善する 45ページ

リファクタリングは振る舞いを変えてはいけないらしい。
長い処理を小さく分割したり、複雑な分岐をシンプルにしたり、正しく命名するなどコードの可読性や保守性を高めるために行う作業のことをリファクタリングと言っているようだ。

リファクタリングの目的

ソフトウェアの設計を改善する、ソフトウェアを理解しやすくする、バグの発見を助けるといったメリットがあったが、生産性を上げるために集約される。
リファクタリングをしないと、プログラム内部の設計が徐々に劣化していく。
設計が練られず、短期的な目標の実現のために追加されたコードなどが積み重なってコードを読むことが困難になる。
こうしたコードの中で機能を追加する場合、設計の良いコードに比べてより多くのコードを書く必要もあり工数が増える。
リファクタリングを継続的に行うことでこうした問題を防ぐことができ、生産性が上がる。

リファクタリングの第一歩

対象となるコードについてきちんとしたテスト群を作り上げること
これをやる理由は、意図せず破壊してしまうことを防ぐため
リファクタリングで既存のコードに手を加えることになるが、自分としては振る舞いを変えていないつもりでも意図せず変わってしまうこともある。
自分のリファクタリングが正しいものか判断するためにテストを事前に用意して振る舞いの正しさを定義するべき。

いくつかの疑問

リファクタリングを避けるべきときは？

実際に触ることがない箇所のコードや、あまり使われていないサービスのコード。
混沌としたコードであっても修正の予定がない箇所や、単なるAPIとしてみなせるならそのままで放置してよい。
どのように動いているのか理解しないといけないときが来たらその時がリファクタリングの利点が出てくる。

いつリファクタリングをするべき？

• 既存のコードに機能を追加する前の準備のとき
• コードの可読性がいまいちで理解しづらいとき
• 間違っていないけど微妙な設計のコードがあったとき