refactoring

Author: tam315

books/refactoring.md

@@ -358,3 +358,48 @@ const main = () => {
     - ホットスポットを探し出し、集中的に最適化
     - この際、なるべく小さなステップを積み重ねるようにすること（コンパイル->テスト->計測）
   - 短期的にはパフォーマンス悪化があるかもしれないが、チューニング段階からは加速し、最終的には最短で目的を達成できる方法である
+
+## コードの不吉な匂い
+
+- リファクタを「いつ」始めるべきか？
+  - 美意識といった曖昧な感覚ではなく匂いで判定しろ。以下、そのリスト
+
+### 不可思議な名前
+
+- 適切な名前付けは明快なコードにするために最も重要、だけど難しい
+- 良い名前付けができれば
+  - コードがずっとシンプルになる
+  - 将来の時間を大きく節約できる
+- 良い名前付けができないときは、問題を理解できていない兆候
+
+### 重複したコード
+
+- 似ているけど違う部分はないかという間違い探しを毎回やる羽目になる
+
+### 長い関数
+
+- 小さな関数の寿命は最も長い
+  - 自己記述性、共有性、選択可能性が高いから
+- 関数の分割をすると読むときのオーバーヘッドが増えないか？
+  - 関数名をわかりやすくして対処する
+    - そうすれば中身を読まずに読み進められる
+    - コードが何をするのかという「意図」を表す名前をつける
+    - コードが長くなっても意図が明確になれば良し
+- やること
+  - `関数の抽出 p112` (コレが 99%)
+    - 以下を関数に抽出してわかりやすい名前をつけていく
+      - 重複コードなど、まとめられる箇所
+      - コメントがある部分（≒ わかりにくいコード）
+      - 例え 1 行でも躊躇しない
+    - パラメータや一時関数が多すぎる場合
+      - `問い合わせによる一時変数の置き換え p185`
+    - 引数が多すぎる場合
+      - `パラメータオブジェクトの導入 p146`
+      - `オブジェクトそのものの受け渡し p327`
+    - それでも一時変数やパラメータが残る場合
+      - `コマンドによる関数の置き換え p345`
+  - 条件分岐やループには`条件記述の分解 p268`
+  - 巨大な switch 文があるなら、分岐後の各処理を`関数の抽出 p112`
+  - 同じような構造の swtch 文が複数あるなら、`ポリモーフィズムによる条件記述の置き換え p279`
+  - ループ部分とループ内部を`関数の抽出`
+    - 抽出した関数にうまく名前がつけられないときは、ループとは別のことをしているので`ループの分離 p236`