第2章 リファクタリングの原則
リファクタリングの定義…
外部から見た振る舞いを保ちつつ、理解や修正が簡単になるようにソフトウェアの内部構造を変化させること
ソフトウェアの開発を、機能追加とリファクタリングの２つの活動に区別するべき
機能追加するときに、既存のコードを変更してはいけない
リファクタリングするときに、機能追加を行わないようにする
リファクタリングを行う理由
- ソフトウェア設計を改善する
- アーキテクチャは徐々に劣化する
- リファクタリングをすることで、より良い状態を保つことができる
- ソフトウェアを理解しやすくする
- コードの目的がより伝わるようになる
- 実現したいことを明確に表現できる
- バグの発見を助ける
- プログラムの構造を明確にすることにより、コードに対する推測が正しかったとわかり、やがてバグを無理なく発見できる
- プログラミングを速める
- コードを把握する時間が短くなる
リファクタリングをするタイミング
普段の作業中に、三度同じようなことをしていると気づいたなら、リファクタリングをするタイミング
- 準備のためのリファクタリング
- 機能を追加する前にやる
- バグ修正をする際も同じ
- 理解のためのリファクタリング
- コードが何をしているか理解しづらいときには、リファクタリングを行う
- リファクタリングによって、頭の中の理解をコードに移し替える
- ゴミ拾いのためのリファクタリング
- コードが何をしているかはわかるものの、書き方がいまいちなときに行うリファクタリング
- 計画されたリファクタリングと、機に応じたリファクタリング
- リファクタリングに専門の時間を設けるよりも、なにかの作業中にするのが普通
- これまでリファクタリングを軽視してきた結果、纏まった時間が必要になる場合もある
- 長期のリファクタリング
- 殆どのリファクタリングは、数分から数時間で終わる
- しかし、時には一週間以上かけて行う場合もある
- その場合にも、リファクタリングに専念するのはおすすめできない
- コードレビュー時のリファクタリング
リファクタリグの問題点
- 新機能の実装が遅くなる
- 多くの人がこういう認識
- 追加する機能が些細な場合は、リファクタリングを後回しにすることもある
- コードの所有権
- コードの所有者による境界は、リファクタリングの妨げになる
- そのため、強いコードの所有権を細かく設定するのはだめ
- ブランチ
- 機能ブランチを長く使っていると、統合が大変になる
- CIを使うことで、その統合が楽になるだけじゃなく、リファクタリングとの相乗効果もある
- テスト
- リファクタリングをしたいなら、自己テストコードが必要になる
- レガシーコード
- リファクタリングはレガシーシステムを理解するための素晴らしいツールになる
- 一度にきれいするのはおすすめできない、少しずつやる
- データベース
- 複数のリリースに分割して行う
感想
開発のときに、ついでにリファクタリングしたのを機能追加のcommitに入れるのは良くないのかなぁ
commit messageに絵文字やプレフィックスを入れることに抑圧できる部分でもありそう？
例 add hoge refactoring fuga や、 :sparkles: hoge :hammer: fuga
参考. GitCommitEmoji