13.9.2 いつリファクタリングを行うかについての7つの戦略

内容

リファクタリングできるコードはかなり多いはずだ。
基本的に触ることもないし、拡張する必要もないコードはリファクタリングしなくてもよい。
ここでは何をいつリファクタリングすれば効果的なのかを判断するための7つの戦略を紹介。

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

学び

  • リファクタリングできるタイミングは意外と多い

学びを活かすアイディア・行動

  • 何をいつリファクタリングできるか整理
  • リファクタリング内容と関連しているコードの整理

Tags:

No responses yet

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です