自分の考えるリファクタリング指針

なにこれ?

文書化して明確にしてみよう

目次

  1. 何故リファクタリングをするか?
  2. リファクタリングの優先順位
  3. 性能改善との兼ね合い
  4. どこまでリファクタリングすべきか?

1. 何故リファクタリングをするか?

  • 可読性を上げるため
    • 何故可読性を上げるか?
      • 品質を上げるため
      • 開発速度を上げるため
  • 可読性の高いコードの利点
    • バグを発見しやすい(品質up)
    • 不具合発覚時に修正がし易い(品質up)
    • 機能の追加がしやすい(開発速度up)
    • 再利用しやすい(開発速度up)

ぶっちゃけもう二度と機能追加/修正をしないコードはリファクタリングする必要はない

  • でもなんだかんだ手を入れる事になるんだよね...

2. リファクタリングの優先順位

テスト -> リファクタリング -> 機能追加

3. 性能改善との兼ね合い

  • 可読性を上げたために速度が遅くなった! なんてことはあんまりないので、そこまで気にしなくて良いと思う
    • 理想をいえばCIに性能計測を仕込んで、リファクタリング前後で計測できると良いのだけど...
  • リファクタリングと性能改善は別の作業なので、同時に行わない

4. どこまでリファクタリングすべきか?

個人的な指針なので異論はあると思う

自己満足のリファクタリングはしない

必要に応じたリファクタリングをすべき

リファクタリング前に問うこと

リファクタリングをすべきとき

  • 機能追加の前
    • 積極的にすべき
    • コードを理解するために
    • 追加すべきコードの量を減らすために(品質/生産性up)
  • 機能追加の後
    • コードレビュー時など
    • リファクタリングが行われる最後のチャンスと思っても良いかもしれない
  • 汚いコードを見つけた時
    • ただし、他の作業との優先度は兼ね合うべき
  • 性急な機能追加が一区切りついた時
    • 一区切りつく前に、生産性や品質について課題が発生している場合は絶対にやるべき
    • プロダクトオーナーに了承を取って、一定の期間をリファクタリングに費やす
      • これ以降の生産性や品質が上がります! という形で説得する
      • 課題感を共有できていれば説得できるはず