13.9.2 いつリファクタリングを行うかについての７つの戦略
内容
リファクタリングできるコードはかなり多いはずだ。
基本的に触ることもないし、拡張する必要もないコードはリファクタリングしなくてもよい。
ここでは何をいつリファクタリングすれば効果的なのかを判断するための７つの戦略を紹介。
| 戦略 | 説明 |
|---|---|
| 重要なコードがうまく保守されていないとき | 明らかに主要機能で、今後も修正は見込まれるけど、複雑になりすぎている場合。 まずはテストコードから追加しよう。 |
| コードを理解している人がいなくなったとき | いなくなる前に、関連コードを修正する場合は、そのキーパーソンがクリーンアップしよう。 基本全員が扱える状態を目指そう。 |
| 新しい情報によって、より良い設計が見つかったとき | 今の設計を改修するコストよりもメリットが大きい場合リファクタリングが選択肢となる。 |
| バグを修正するとき | テストがなかったからバグが発生したと考えることができる。 テストを書いてついでにリファクタリングするとよいだろう。 |
| 新機能を追加するとき | 安全に機能追加する方法は、まず機能追加できるようにリファクタリングしてから機能追加すること。 |
| レガシーコードのドキュメントを書くとき | 難解なコードを理解するためのドキュメントに起こすとき。 製造中であれば設計を見直し、リファクタリングできるか検討しよう。 |
| 作り直すより安いとき | 同じような開発プロセスで作り直す場合、高い確率で同じような技術的負債を産む。 リファクタリングをプロセスに組み込む方が安くなるか検討しよう。 |
学び
- リファクタリングできるタイミングは意外と多い
学びを活かすアイディア・行動
- 何をいつリファクタリングできるか整理
- リファクタリング内容と関連しているコードの整理
