refactoring

Author: tam315

books/refactoring.md

@@ -241,3 +241,52 @@ const main = () => {
 
 - 単なる API とみなせて、かつ今後の修正の必要がないとき
 - ゼロから書き直したほうが早いとき
+
+### リファクタリングの問題点
+
+#### 新機能の実装が遅くなる
+
+- リファクタの目的はプログラミングの速度を上げること
+- よって実装は遅くならない
+- ただしトレードレードオフもある。このあたりは経験がモノを言う。
+  - リファクタする場合の例
+    - 以後の作業が楽になるとき
+    - 何度も同じ問題が起きているとき
+    - 同じような醜いコードに何度も出くわしているとき
+  - リファクタしない場合の例
+    - 新機能が非常に些細なもので、リファクタを後回しにできるとき
+    - めったに触らない箇所であるとき
+- 道徳的な理由でリファクタしようとするのは危険
+  - 「コードが美しくなる」とか
+  - 「(しばしば原理主義的な)すばらしいプラクティスにコードを近づける」とか
+- 経済的な基準でのみ判断せよ
+
+#### コードの所有権
+
+- コードの部分ごとにオーナーを設定し、変更を承認するようなやり方が良いのでは
+- これは、以下の 2 つの間を取ったもの
+  - 所有権が強すぎて、リファクタが困難な状態
+    - e.g. 関数名を変えたときに、呼び出し元のコードを変更できない場合など。こういったときは古い関数から新しい関数を呼び出すようにして、古い関数には deprecated を指定するなどするものの、最悪の場合、古い関数は永遠に残り続けることになる。
+  - 所有権がなくて、誰もが好き勝手に変更を加えてカオスになった状態
+
+#### ブランチ
+
+- Feature branch 方式はリファクタリングと相性がとても悪い
+  - ブランチの生存期間とマージの困難さは指数関数的に相関する
+  - マージが難しくなることを理由にリファクタを諦める場合もあるくらい
+  - バージョン管理システムは意味的な変更にすこぶる弱い
+    - 意味的な変更 ≒ リファクタリング。例えば関数名の変更など
+- Trunk-based なブランチ戦略がおすすめ
+  - 1 日 1 回はメインブランチに統合する方法
+  - ただし、大きな機能を小さな機能に分割したり、分割できない大きな機能を無効化する Feature flags の仕組みを作ったりするなどの準備が必要
+  - Feature branch 方式と併用も可能。何れにせよなるべく頻繁にメインブランチにマージする。
+
+#### テスト
+
+- テストは必須。テストがあれば：
+  - リファクタが容易になる
+    - 間違いにすぐ気づくので、見るべきコードの範囲が狭まるから
+  - 新機能追加がやりやすくなる
+    - 新たに埋め込んでしまったバグにすぐ気づくから
+- テストがない or 少ない場合は、IDE に安全が保証されている自動実行できる種類のリファクタであれば、実施できるかも
+  - ただし注意深く手順に従う必要があるし、言語仕様にも依存するので比較的高度なやり方