変更を最小にするためのリファクタリング
💪やること
追加や変更を行う際、同様の理由で変更する箇所が複数発生する場合、変更の前にリファクタリングを行う。
このリファクタリングでは「変更箇所を1カ所にする」を目的に重複を取り除く。
決して追加や変更を行わない。
リファクタリングのみでコミットし、明確に区切る。
🚩目的
リファクタリングを終えられるようにする。
🤔経緯
リファクタリングは健全なプロダクトに必要であるが、どこまでやればいいかははっきりしないところがある。
全てのリファクタリングは逆向きのリファクタリングも可能なため、リファクタリングだけを考えれば終わりはない。
また、リファクタリングの費用対効果は測りづらい。
機能追加や変更を行う前に、変更対象をリファクタリングすることで、設計を洗練させられる。
変更箇所が最小になったら終了する。この後実際に変更を行った場合に最小になってなかったとしても、改めてリファクタリングに戻ることは強制しない。リファクタリングに戻る場合は変更はcommitせずrevertして混ぜないこと。
リファクタリングが必要になるのは、よく変更をするホットスポット。このパターンによりホットスポットに絞っての「容赦の無いリファクタリング」(出自忘れた)が適用できる。
🏆結果
変更が連動すべきところ、すべきでないところがコードに反映される。