リファクタリング。

たまにはIS01以外の記事を書く。

ソフトウェア技術者であれば一度は聞いたことがあるかもしれない「リファクタリング」。

この言葉を聴いた方はどの様な印象を持たれるのだろうか。

---

僕がこの言葉に出会ったのは、2005年。今から7年前。

当時、XPを独学で学び、様々なプラクティスを実践していったのだが、「リファクタリング」が一番最後になってしまった。理由は、「面倒だったから」。

ペアプロやTDDは理解に苦しまなかったのだが、リファクタリングだけは理解することができなかった。

バイブルである　「リファクタリング　―プログラムの体質改善テクニック」　を会社の経費で購入したものの、理解できず、読んでると眠くなってきてなかなか覚えることができなかった。

とはいえ、やっぱり興味があったので、なんとか覚えようと、自分で　「リファクタリング手順書」　を作成することにした。

本に記載されているパターンをExcelに転機。当時、C++で開発していたので、JavaをC++に変換しながらプログラムをExcelに記載した。その甲斐あって、ようやく　「リファクタリング」　を理解することができた。

理解した瞬間、「なんて効率的かつ効果的なプログラム改善テクニックなんだ！」と驚くと共に、「面度くさっ！」と顔をしかめた。

簡単に説明する。たとえば、既存の関数の中身を修正し、より良い設計に改善する場合を挙げる。

-----------------------------------------------
１．既存の関数（A)をコピーして、新しい関数（B)を作る。

２．新しい関数（B)のテストがパスするユニットテストを作成する。

３．（B)を変更し、テストがパスすることを確認する。

４．既存の関数（A)を呼び出している場所を、（B)に置き換える。

５．テストする。
　　※　（Ａ）　→　（Ｂ）を呼び出している箇所全てに対し、４．～５．を繰り返し実施する。
　　　　 （Ａ）が100箇所から呼ばれていれば、100回繰り返す。

６．（Ａ）を削除する。

-----------------------------------------------


上記手順であれば、バグの混入は激減することができる。
そして、１．～６．でビルドが通る状態であれば、どのタイミングでもコミットすることができる！修正途中かどうか考える必要が無い。

……ただ、手間が掛かる。

---

リファクタリングを実施する際、テストによる変更内容確認が必用である。

上記　２．と　５．でテストを実施しているが、変更箇所が多ければ多いほど、テストの回数が増えて行く。テストの手間を省くためにも、自動テストは必須だと言える。

自動テストが無いのであれば、手動でテストを行わなければならず、リファクタリングの手間はいっそう増えることだろう。「テストが面倒」だと言って手を抜くと、痛い目に遭うことは想像に難くない。

---

■結論。

言いたかったのは、

「リファクタリングの手順を理解せずに”リファクタリング”することは、自殺行為と同意」

である。

正しいリファクタリングの知識を是非身につけて欲しい。


■チャートでわかるリファクタリング