なにこれ?
リファクタリングが尿を漏らしそうなくらい好きなのだけれど、気分に任せるままやっている節があるので、自分の中ののリファクタリング指針を明確にしたい
— かせいさん#C90(金)東エ04-a (@kasei_san) 2016年7月14日
文書化して明確にしてみよう
目次
1. 何故リファクタリングをするか?
- 可読性を上げるため
- 何故可読性を上げるか?
- 品質を上げるため
- 開発速度を上げるため
- 何故可読性を上げるか?
- 可読性の高いコードの利点
- バグを発見しやすい(品質up)
- 不具合発覚時に修正がし易い(品質up)
- 機能の追加がしやすい(開発速度up)
- 再利用しやすい(開発速度up)
ぶっちゃけもう二度と機能追加/修正をしないコードはリファクタリングする必要はない
- でもなんだかんだ手を入れる事になるんだよね...
2. リファクタリングの優先順位
テスト -> リファクタリング -> 機能追加
- テスト -> リファクタリングは絶対
- リファクタリング -> 機能追加は状況次第で
- ぶっちゃけ、機能追加のついでにリファクタリングすることがほとんど
- あんまりにもなコードを見つけてしまった時に、リファクタリング専用のチケットを作るときもなくはないけど...
3. 性能改善との兼ね合い
- 可読性を上げたために速度が遅くなった! なんてことはあんまりないので、そこまで気にしなくて良いと思う
- 理想をいえばCIに性能計測を仕込んで、リファクタリング前後で計測できると良いのだけど...
- リファクタリングと性能改善は別の作業なので、同時に行わない
- 性能改善して、汚くなったコードをリファクタリングという流れが良いと思う
4. どこまでリファクタリングすべきか?
個人的な指針なので異論はあると思う
自己満足のリファクタリングはしない
必要に応じたリファクタリングをすべき
