「リファクタリング」を読んでリファクタリングの重要性を理解し、実践してみました。

はじめに

リファクタリングを読みました。一番最初に具体的なコードとともにリファクタリングの詳しい解説があり、リファクタリングの重要性とすごさを感じました。
この本を読んだ後、実際にリファクタリングしてみて感じたことをキーワードと共にまとめます。

リファクタリングは外部からの振る舞いを変えず内部構造を変えること

リファクタリングの定義として記載されています。「外部からの振る舞いを変えない」ということが重要で、それがリファクタリングを確実に実施する方法です。内部構造を変えてきれいなコードにすることで、品質を上げていくことになります。

リファクタリングには自動化したテストが必要

「外部からの振る舞いを変えない」ということで、リファクタリングする上で自動化したテストが重要です。

OKとなるテストがあれば、そのテストが常にパスすることを確認しながら、内部構造を変えることで、自信を持ってリファクタリングを実施できます。リファクタリングは一気にやるのではなく、少しずつ内部構造を変更して、テストを繰り返すことで実施します。テストを何度も何度も実行するので自動化したテストは必須になってきます。

自動化したテストの重要性ややり方を知るためにはテスト駆動開発入門がおすすめです。

2つの帽子をかぶり分ける

リファクタリングは「外部からの振る舞いを変えず内部構造を変えること」ですので、「リファクタリングするとき」と「機能追加するとき」の2つの帽子をかぶり分けることが大切です。

リファクタリングしている時に思いついて機能追加したくなることが多々あるのですが、そうするとテストが失敗したときにリファクタリングで失敗したのか、機能追加で失敗したのかわからなくなります。

他にも機能追加でバグがあるためにテストが成功して、リファクタリングも機能追加もバグということもありました。機能追加時にはテストの追加も必要になるので、テスト自体のバグもあり得ます。

リファクタリングの定義の通り、「外部からの振る舞いを変えず」に実施することで、テストによる裏付けをもって、確実にリファクタリングできます。「2つの帽子をかぶり分ける」のを常に意識して、リファクタリングをすることが重要です。

 プログラムに新規機能を追加するときは機能追加が簡単になるようにリファクタリングしてから追加を行う

機能追加するときに「構造を変えてから追加した方がよいかな」と思うことがあると思います。しかし「構造を変えるのは面倒」「このままでも何とか機能追加できそう」といった気持から、まず機能追加したくなります。そして結果的に構造を変更することになったり、汚いコードになりながら「最初に構造を変えておけばよかった」と思うことがあります。

機能追加の前にリファクタリングを行うことで、機能追加時のストレスが違います。リファクタリングしながら追加する機能のことを考えるため、機能追加時はスムーズに開発できます。リファクタリングに時間をかけて、機能追加は一瞬ということもありました。

追加する機能を思いついたときは早く追加したくてウズウズしてしまうのですが、そこをグッとこらえてリファクタリング。その後の機能追加。その過程がストレスフリーで爽快感を感じます。それを実感した後でも「すぐに機能追加」の誘惑に負けてしまうことがあるですが、先にリファクタリングを基本動作にしたいと感じます。

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

3度目の法則

2度同じことをやったら重複や無駄があるなと感じながら、3度目はリファクタリングをします。重複や無駄を除くということです。

機能追加の前

上で解説した通り機能追加の前にリファクタリングです。

バグフィックスの時

コードを理解するために行います。バグを埋め込むということは、コードを理解していなかったり、バグを見つけにくい構造になっていたりしていたためです。

リファクタリングをすることでコードを理解して、バグを埋め込みにくい構造にします。

コードレビューの時

コードレビューの時にリファクタリングをすることで、コードを理解し、さらにアイディアも生まれてきます。この究極的な形がエクストリーム・プログラミングのペア・プログラミングになります。

変数名の変更は人間にとってわかりやすいコードになるため大切

一番簡単なリファクタリングである変数名の変更です。

有名な書籍「リーダブルコード」にも書いてありますが、コードがわかりやすいように変数名を決めることは重要です。コードが読みやすい=理解しやすい=バグが埋め込まれにくいだと思います。

switch文をポリモーフィズムを使って置き換えできる

デザインパターンのState/Strategyパターンです。この本を読むまではポリモーフィズムの利点がわかっていませんでしたが、「switch文をポリモーフィズムを使って置き換える」のは目から鱗でした。

保守性、拡張性ともにサブクラスのみの変更や追加で行えるのは素晴らしいです。

コードの不吉な臭い

リファクタリングすべき時の「コードの不吉な臭い」です。たくさんあるのですべてを理解するのは難しいのですが、理解しやすいのは「重複したコード」「長すぎるメソッド」「巨大なクラス」「長すぎるパラメータリスト（多すぎる引数）」「スイッチ文」でしょうか。

後は変更時に必ず影響を受けるコード「変更の偏り」やある変更で影響範囲が広くなってしまう「変更の分散」はリファクタリングすべきコードです。

一時的に見逃せばその時に機能追加はできるのですが、その後のことを考えるとリファクタリングしておいた方がよいです。「コードの不吉な臭い」を感じたらリファクタリングをするようにしたいです。

おわりに

この本を読んでリファクタリングの具体的な例を学ぶとともに、その重要性を理解できました。リファクタリングは機能追加しないために、実施するには重い腰を上げる必要があるのですが、実施するとその効果は目を見張るものがあります。特に開発時にストレスフリーになるのが、一番の効果だと感じます。

またリファクタリングを実際に行ってみると、間違い探しのようにゲーム感覚で楽しめます。コードがきれいになった後に機能追加することで、ストレスフリーで開発できます。継続的にリファクタリングをしていきたいです。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)