リファクタリングのいつ

リファクタリングのタイミングはいつなのかという問いについて。

ベストなのは開発と並行して。
書いたばかりのコードはリファクタリングしやすい。
時間が経つほど内容を忘れていくのでリファクタリングしにくくなる。

ありがちなのは「時間が余ったらリファクタリングしよう」
時間は得てして余らないものなので、リファクタリングの機会は永久に来ない。

リファクタリングは余った時間でするものではない。
むしろ時間を余らすためにリファクタリングすると言ってもいいくらい。
リファクタリングによってコードがシンプルで修正しやすい状態に保たれるため、開発スピードを保つことができるからだ。
(という口車を使ってリファクタリングの時間を確保しよう!)

リファクタリングは「外部から見た振る舞いを変えずに実装を変えること」なので、振る舞いを変えるものを「リファクタリング」とは呼ばない。それは単なる「修正」。
リファクタリングの最中に何かをひらめいたら、改めて修正を加えるのは問題ない。
その場合はリファクタリングを中断して修正に作業を切り替えること。気の利いた言い方をするならば帽子をかぶり直す。

自動テストは外部から見た振る舞いが変わらないことを保証してくれるので、リファクタリングにはきわめて有用。
というかセットとして扱うべき。
自動テストなしのリファクタリングは命綱なしのロッククライミングのようなもの。
天才はやっていい。凡人はやったら死ぬ。
凡人はリファクタリングするときに対象となる箇所にテストがなければテストを書く。

というわけでリファクタリングを実践的にやっていくためにはプロダクトコードと同時にテストコードも書いていくと具合がよろしい。それによって開発と並行してリファクタリングしていくことができる。

(先日もう終わりと言ったがこれはTDDBC 福岡2ネタかもしれない)

この投稿へのコメント

コメントはありません。

コメントを残す

メールアドレスが公開されることはありません。

この投稿へのトラックバック

トラックバックはありません。

トラックバック URL