修正時に一箇所リファクタリングする

最近仕事でバグ修正をするときには、必ずその周辺のリファクタリングを一箇所行うという事をしている。今日はそのことについて書いてみる。

時間が経つとコードはレガシーになる

これは自分の感覚でしかないのだが、コードというのはどんなに素晴らしい人が書いたとしても、時間が経つと必ずレガシーコードになると思っている。これには例えば以下の理由などがある。

技術が進む
- 昔は無理やりやらないといけなかったものが、ミドルウェアを入れると簡単に出来るようになったとか
コーディング規約が変わる
- 人が増えるなど、外部要因によってコーディング規約が変わるけど、昔のコードは思想が違うとか

そのため、少しずつリファクタリングの時間を設けないとどんどんレガシーなコードが作られていく。

修正時、一箇所修正する

それでリファクタリングをしたいのだけど、ずっとリファクタリングをするのもモチベーションを維持できないし、リファクタリングをしすぎることによって機能開発やバグ修正が遅れてしまったら本末転倒なので、最近はバグ修正時に一つリファクタリングをするということを心がけている。
例えば

編集機能にバグが見つかりました
そのバグ周辺のテストを書く
周辺のテストが増えたので、そのバグ周辺のリファクタリングを一箇所する
- 一箇所の定義は難しいけど、わかりづらい部分の一部分をモジュールもしくはメソッド化とか

みたいな感じ。

ただしあんまり大きいリファクタリングをしないといけないことが分かった時には、その時にはせずに、タスク化してしまって別の機会にやるようにしている。バグ修正なのにリファクタリングしているせいでリリースが遅れるとか、レビューの時に見る範囲が増えるとか、色々理由があるけどそういうふうにしてる。

リファクタリングは一気にやるべきみたいな意見もあると思うし、そうしたほうがよい部分もあると思うけど、全部が全部そうできるとは限らないと思うし、それであまりにもモチベーション低下や開発速度*1が下がるのではあまり意味が無い。ので、ちょこちょこ直してくっていうのと、一気に直してくというのを合わせて使ったほうがいいと思った。

まとめ

リファクタリングについて書いたけど、自分はリファクタリングの書籍をまだちゃんと読んだこと無いので、ほとんどが自分の感覚になってしまっている。これは良くないので、ちゃんとその辺の本も読まないとなと思った。
例えば最近はコードコンプリートとかを読んでる。この中にはリファクタリングの話も書いてあって参考になる。他にもリファクタリング―プログラムの体質改善テクニック (Object Technology Series)を読んだりしたい。