リファクタリングを行うタイミングはいつ？
言わずと知れた名著、「リファクタリング」の第2版を読んでいます。
関数の抽出や適切な命名など、リファクタリングに関するテクニックは色々とありますが、それとは別に 「いつリファクタリングを行うのか」 について面白い記述があったのでメモ用にまとめておきます😊
以下３つです。
- 準備のためのリファクタリング
- 理解のためのリファクタリング
- ゴミ拾いのためのリファクタリング
準備のためのリファクタリング
「機能追加を容易にする」というのはリファクタリングの大きな目的の１つです。
そして機能追加を行うタイミングこそがリファクタリングを行うのに適したタイミングだと著者は言います。
機能追加の際には既存のコードを読むと思いますが、この時少しでも構造が違っていたら作業はずっと簡単になるだろうと頭の中で考えます。
この時、 もうリファクタリングを行ってしまう のです。
バグ修正でも同様です。
簡単そうなら先にリファクタリングを行ってしまい、それから機能を追加した方がよっぽど楽なはずなのです。
これは機能追加とリファクタリングを同時に行うということでは無いと理解しています。
「先に」リファクタリングを行うだけです。リファクタリングの時は機能追加のことは考えるべきではありませんし、逆も然りです。
機能追加というきっかけがリファクタリングの必要性に気づかせてくれます。
理解のためのリファクタリング
機能追加でなくとも、コードは読みます。
そして往々にして 「なるほど、分からん」 状態になります。
この気付きを封じ込めず大切にするべきです。
なぜパッと見て分からないコードになってしまうのでしょうか。
理由は色々あると思います。
- 関数が長い
- 分岐が複雑
- 無駄なパラメータが多い
- 命名が不適切
これらは全てリファクタリング中に対処する項目として一般的でしょう。
であれば、「理解（コードを読む）」ためにこのタイミングでリファクタリングをしても良いはずなのです。
きっと他の人も読みにくいものなのでしょうから、リーディングついでに少しでも修正できればチームを助けることもできるでしょう🙋♂️
ゴミ拾いのためのリファクタリング
これは「理解のためのリファクタリング」と似ています。
コードが何をしているかは分かるという点で、「理解のためのリファクタリング」より状況はマシかもしれません。
しかし 「イケてない」 のです😭
だから目の前に落ちている小さなゴミを見かけたら拾いましょう。
リファクタリングの良いところは小さなステップを踏めるところです。一度に全部やらなくて良いですし、そのティッシュ１つを拾ったことが将来役に立つのです。
ゴミ拾いに夢中になりすぎて本来のタスクを忘れてはいけません。
未来への種蒔きですから、あまりにも時間がかかりそうな巨大ゴミなら対応をチームで別途検討しましょう。
リファクタリングって計画してやるもの？
個人的に1番おもしろいなと思ったのが、 リファクタリングは専用の時間を取ってやるものなのか？ という議論です😎
私の開発経験からすると、どちらかというと別途リファクタリングの時間を取っていることが多かった印象です。
まとまった時間が取れることは少なかったですが、やるなら機能の拡張などと PR を分けることが多かったです。
ただ、著者に言わせるとこれは無駄なようです（反省）。。。
リファクタリングは呼吸をするように、コーディングをしている最中にごく自然にやるものだと言います。
機能の追加や、バグの修正中に適宜行うものなのです。
なぜなら、プログラミングをする以上リファクタリングは不可欠なものであるからです。
だから専用の時間を確保するようなものでは無いと。
次の1文がカッコいいのでシェアします👨💻
「if 文を書くためにわざわざ専用の時間を設けないのと同じです。」
刺さる〜😇
今回はリファクタリングのタイミングについて書きましたが、これら全ての話が役立つのは 自動テストが書かれていること が前提です。
だから今日もしっかりテストを書いていきましょう😆！！
Discussion