refactoring

Author: tam315

books/refactoring.md

@@ -309,7 +309,7 @@ const main = () => {
 
 - リファクタリングという武器を手にすると:
   - 現時点で判明している最低限の要件を満たすだけの、最もシンプルなコードを書きさえすればよい
-  - 将来のために変に柔軟性を持たせたりしない
+  - 将来のために変に柔軟性を持たせたりしなくてすむ
     - e.g. 関数に無駄にたくさん引数持たせるなど
     - Yagni = You ain't going to need it = どうせ使わねえよ
     - リファクタリングできるんだから、必要になった段階で変更すれば足りる
@@ -324,13 +324,13 @@ const main = () => {
     - ソフトウェアがいつでもリリース可能な状態であること
   - リファクタリング
 - コアプラクティスがもたらすもの
-  - Yagni を実践できる
   - リリースを素早くできる
   - リリースのリスクを減らせる
   - リリースの技術的制約が減る
   - アイディアを最速で顧客に届けられる
   - ソフトウェアの信頼性を高める
   - 修正に時間のかかるバグを減らせる
+  - Yagni を実践できる
 - アジャイル開発の必要条件
   - コアプラクティスが全て実践されていること
   - メンバーが：
@@ -343,61 +343,75 @@ const main = () => {
 パフォーマンス最適化には 3 つの方法がある
 
 - 実行スケジューリングする方法
-  - 時間やメモリ使用量といった制約を与えて開発する
+  - 実行時間やメモリ使用量の制約を与えたうえで開発する
   - ハードリアルタイムシステム向き
-- パフォーマンスを常に気にしながら開発する方法
+- パフォーマンスを**常に**気にしながら開発する方法
   - この方法はあまりうまくいかない。なぜなら：
-    - パフォーマンスはごく一部のコードが引き起こすので、均等に努力しても大半は無駄に終わる
+    - パフォーマンス問題はごく一部のコードが引き起こすので、均等に努力しても大半は無駄に終わる
     - パフォーマンス最適化のためのコードが至るところに散らばる
     - コードがわかりにくくなる
-- きれいに作って後でチューニングする方法
+- きれいに作って**後で**チューニングする方法
   - まずはプログラムをきれいにつくる
     - この際パフォーマンスは気にしない
   - チューニングの段階まできたら以下を行う
-    - プロファイラによる計測
-    - ホットスポットを探し出し、集中的に最適化
-    - この際、なるべく小さなステップを積み重ねるようにすること（コンパイル->テスト->計測）
+    - プロファイラによる計測をする
+    - 最も悪影響を及ぼしている箇所から順に最適化していく
+    - この際、なるべく小さくステップを積み重ねること（コンパイル->テスト->計測）
   - 短期的にはパフォーマンス悪化があるかもしれないが、チューニング段階からは加速し、最終的には最短で目的を達成できる方法である
 
 ## コードの不吉な匂い
 
 - リファクタを「いつ」始めるべきか？
-  - 美意識といった曖昧な感覚ではなく匂いで判定しろ。以下、そのリスト
+  - 美意識といった曖昧な感覚ではなく匂いで判定しろ。以下、匂いのリスト。
 
 ### 不可思議な名前
 
-- 適切な名前付けは明快なコードにするために最も重要、だけど難しい
-- 良い名前付けができれば
+- 名前付けの対象
+  - 関数名
+  - 変数名
+  - フィールド名
+- 適切な名前付けは：
+  - 明快なコードにするために最も重要
+  - 難しい
+  - リファクタリングに置いて最も多く行われる作業
+- 適切な名前付けがでできれば：
   - コードがずっとシンプルになる
   - 将来の時間を大きく節約できる
-- 良い名前付けができないときは、問題を理解できていない兆候
+- 適切な名前付けができないときは問題を理解できていない兆候
 
 ### 重複したコード
 
 - 似ているけど違う部分はないかという間違い探しを毎回やる羽目になる
+- 複数メソッドに同じ式がある時
+  - `関数の抽出 p112`
+- 似ているけど完全に同一ではない時
+  - `ステートメントのスライド p231`で似た箇所を寄せておく。せめて。
+- サブクラスに重複したコードがある時
+  - `メソッドの引き上げ p358`
 
 ### 長い関数
 
-- 小さな関数の寿命は最も長い
-  - 自己記述性、共有性、選択可能性が高いから
+- 小さな関数の寿命は最も長い。なぜなら以下が高いから。
+  - 自己記述性
+  - 共有性
+  - 選択可能性
 - 関数の分割をすると読むときのオーバーヘッドが増えないか？
-  - 関数名をわかりやすくして対処する
+  - 関数名をわかりやすくすれば増えない
     - そうすれば中身を読まずに読み進められる
     - コードが何をするのかという「意図」を表す名前をつける
     - コードが長くなっても意図が明確になれば良し
 - やること
-  - `関数の抽出 p112` (コレが 99%)
-    - 以下を関数に抽出してわかりやすい名前をつけていく
-      - 重複コードなど、まとめられる箇所
-      - コメントがある部分（≒ わかりにくいコード）
-      - 例え 1 行でも躊躇しない
-    - パラメータや一時関数が多すぎる場合
-      - `問い合わせによる一時変数の置き換え p185`
-    - 引数が多すぎる場合
-      - `パラメータオブジェクトの導入 p146`
-      - `オブジェクトそのものの受け渡し p327`
-    - それでも一時変数やパラメータが残る場合
-      - `コマンドによる関数の置き換え p345`
+  - 重複コード、まとめられるコード、コメントがあるコード（≒ わかりにくいコード）がある場合
+    - `関数の抽出 p112` (コレが 99%)
+      - わかりやすい名前をつけていくこと
+      - 例えコードが 1 行でも必要なら抽出を躊躇しないこと
+  - パラメータや一時関数が多すぎる場合
+    - `問い合わせによる一時変数の置き換え p185`
+  - 引数が多すぎる場合
+    - `パラメータオブジェクトの導入 p146`
+    - `オブジェクトそのものの受け渡し p327`
+  - それでも一時変数やパラメータが残る場合
+    - `コマンドによる関数の置き換え p345`
   - 条件分岐やループには`条件記述の分解 p268`
   - 巨大な switch 文があるなら、分岐後の各処理を`関数の抽出 p112`
   - 同じような構造の swtch 文が複数あるなら、`ポリモーフィズムによる条件記述の置き換え p279`