自分がリファクタリングするのは機能追加に飽きた時。ペーストしては月１回程度で、多い方だと思う。よく飽きる。
リファクタリングをする時はまず、コードを端から端まで読みながらコメントをしていくところから始める。その後、またコードを端から端まで読みながらコメントを読みつつ、どんなリファクタリングをするか決めていく。そして、決めたらブランチを切って作業。
とにかく、手を付けるコードを読むことが重要だと思っている。人間は適当なものでコードを適当に理解している事が多いので、一度頭を空っぽにしてコードを読むと「この辺は大丈夫」と思っていた部分も全然大丈夫じゃないことがある。
リファクタリングはとにかく機能追加を一切しないのが重要で、既存のコードを読みやすくするためだけの作業に集中する。機能追加をしたいと思ったら、もともとやっていた機能追加開発に戻ろう。
ちなみに、機能追加が辛くなってきた時にリファクタリングすると「ここ、もっと機能追加しやすくすべき」というのが見つけやすくなるという素敵な副作用もある。
リファクタリングしているとよく思うのだが、リファクタリングが好きなタイミングでやれる環境というのが、開発者にとって理想の環境ではないだろうか。
そもそも機能追加ではないので売上に貢献するわけでもない、顧客の要求に答えるわけでもない。それを自由にやれる環境はリファクタリングの良さをを理解していないと難しい。
リファクタリングは製品の寿命を延ばす作業だと思っている。カスタマイズとは真逆なイメージ。
頻繁にリファクタリングができるというのは、その会社に余裕があるということでもあると思う。余裕がなければカスタマイズを強要されてたり、その製品の開発そのものが終了しているだろう。
テストやリファクタリングが大事とは言われるが、会社の経営状態にとても影響するデリケートな部分でもある。
会社の経営状態が良くない中でリファクタリングばかりしていても、それは会社にとってはデメリットでしか無い。
結局はバランスが重要ではあるのだが、経営状態が良い時にリファクタリングをさせてくれる会社は良い会社の指標の一つになりうる。
採用面接時に「最近リファクタリングした内容を教えてください」と聞くのはありだと思う。
