Loading

​HTML5カンファレンスで貰った新装版リファクタリングを10ヶ月ぶりに読んでみた

プロジェクトで使用しているとあるライブラリの作者さんに「いやーこのライブラリまだ需要あったんすねw」と言われてしまったしょっさんです。

さて、今回は2015/01/25に開催されたHTML5カンファレンス内でのプレゼント企画で、1等とも言うべき品を引き当てたにも関わらず10ヶ月間読まなかったクズがお送りする、新装版リファクタリングのポイントを列挙していく記事になります。

↓こんな本

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

この本はリファクタリングを扱った数少ない本の一つで、かなりの人気がある本です。(特にJavaプログラマに)

サンプルコードなどJavaで書かれていますが、他言語のプログラマでも十分有用な内容が満載の本になっております。

それでは私が読んでみて気になったポイントを挙げていきます。


新たなバグを混入させない

リファクタリングはコードをより良く再設計・再構築する作業になります。
そのため、元のコードから大きく変化する場合があるのでバグが新しく混入(エンバグ)する可能性が大きくあります。

では、どのようにしてこのエンバグを防ぐことが出来るのでしょうか?
答えは簡単。

「テストを書くこと」

リファクタリング前には必ずインプット・アウトプットはこうあるべき、というテストを書くこと。
(メソッドなどの小さい単位でのユニットテストですね)
そうすることで、「リファクタリング前は動いていたのにリファクタリング後に動かなくなった・・・」という事態は防ぐことができるはずです。
テスト作成に時間がかかっても良いので、リファクタリングを行う前にはテストを書くようにしましょう。


リファクタリングとパフォーマンスはトレードオフではない

しばしばリファクタリングを行ったせいでパフォーマンスが落ちたということを聞くことがあります。
リファクタリングの本懐は、再設計・再構築によってよりコードを見やすく、分かりやすくすることですので、
確かにパフォーマンスを蔑ろにすることがあります。

しかし、パフォーマンスを盾にしてリファクタリングを避ける事は賢明な判断と言えるでしょうか?
答えはNOです。

リファクタリングは「本来の最適な形に戻す」作業とも言えるので、「最適ではない形」の上で行われたパフォーマンス最適化は理に適っていません。
更に、本書にもあるようにパフォーマンスに関わるようなコードは全体のうちの1割程度で、その1割に対してリファクタリングが影響を与える可能性は低いとも考えられます。

ですので、リファクタリングを行う上でパフォーマンス云々と言われた場合は「まずリファクタリングを行い、その上でパフォーマンス向上を目指す」がベストアンサーでしょう。


デザインパターンを学ぼう

リファクタリングが目指すべき形の一つにデザインパターンがあります。
デザインパターンとはGoF(Gang of Four)と言われる4人が、コードの典型的な解決方法をまとめたテンプレート集のようなものです。

ちなみに本書の中で閑話休題として、何故リファクタリングというものが生まれたのかGoFを絡めたお話が載っていますのでこれは是非とも本書を買って読んで頂きたいです。

デザインパターンを用いることでリファクタリングの正解パターンがすいすい分かるようになりますので、デザインパターン本も本書と合わせて読むとGoodです。

↓有名なGoFデザインパターン本
「オブジェクト指向における再利用のためのデザインパターン

book-design-pattern.jpg


リファクタリングのタイミングは?

リファクタリングをするべきタイミングってなかなか難しいですよね。
「凄くリファクタリングしたいコードを見つけたけど、今はこっちの開発が・・・」といったことがよくあると思います。
そんな時は以下の3つのタイミング指針を参考にしてみてください。

  • 3度目の法則
    もしあるコードに対してリファクタリングしたい!と思うことが計3回あれば、3回目の時がリファクタリングタイミングです。
  • 機能追加時
    機能追加する時が関連するコードをリファクタリングするタイミングです。
    理由は2つあり、1つ目は元のコードの理解のためで、2つ目は機能追加をしやすくするためです。
  • コードレビュー時
    コードレビューの文化が根付いているチームならコードレビュー時もリファクタリングのタイミングになります。
    ここでのリファクタリングはどちらかと言えばベテランが新人に対して良いコードを教えるためのものと言った方が良いかもしれません。

コードの不吉な匂い

本書ではコードをリファクタリングした方が良いと判断する基準として、「コードの不吉な匂い」を挙げています。
単純にプログラマの好みによるところではなく、このコードは直したほうが良い!という指針を様々な種類別に書いています。
これを見ながらリファクタリングしていくことで、コードの不吉な匂いに対する嗅覚が磨かれると思います。

コードの不吉な匂いの項についてあえて詳しくは述べませんが、リファクタリングを一度でもやったことがある人にとっては「あるある」が詰まったTipsが多いと思います。


リファクタリングカタログ

本書の一番の目玉、それがリファクタリングカタログです。
リファクタリングカタログとは著者のマーティン・ファウラー氏が自身の経験を元にリファクタリング名称・リファクタリング方法などを列挙したカタログになります。

本書の中の350ページほどがリファクタリングカタログになっているという力の入りようですので、読むのにかなーり苦労しますがさらっと目を通すだけでも得るものはあるような内容ですので、是非とも本書を買って確かめてみましょう!


以上が、僕が新装版リファクタリングを読んで気になった点などなどです。

他にもリファクタリングの定義や、リファクタリングを渋る管理者の説得方法などリファクタリングに関することなら何でも詰まっていますので、これ一冊あればリファクタリングの猛者になれること受け合いですよ!

著者アイコン

著者しょっさん

プログラマっぽい人。

関連記事