99_bottles_of_oops.md

Sandi Metz「99 Bottles of OOP」の雑な見出し訳

自分用の超雑なメモであり、訳については保証いたしません。

• 1. シンプルさを再発見する
  • 1.1. コードをシンプルにする
    • 1.1.1. シンプルだけど読みにくいコード
    • 1.1.2. 憶測で一般化する
    • 1.1.3. 具体的すぎる抽象化
    • 1.1.4. テストがGreenでもダメなコード
  • 1.2. コードをジャッジする
    • 1.2.1. 独断ベースの評価
    • 1.2.2. 事実ベースの評価
    • 1.2.3. ソリューションを評価する
  • 1.3. まとめ
• 2. TDDでかえって「テストがGreenでもダメなコード」になるとき
  • 2.1. テストを理解する
  • 2.2. 最初のテストを書く
  • 2.3. 重複の除去
  • 2.4. 挙動の変化を理解する
  • 2.5. 重複に寛容になる
  • 2.6. 計画への忠告
  • 2.7. 隠れた責務を暴く
  • 2.8. よい名前をつける
  • 2.9. 隠れた意図を暴く
  • 2.10. コスト効果の高いテストを書く
  • 2.11. 「エコールーム」を避ける
  • 2.12. 注意点
  • 2.13. まとめ
• 3. コンセプトを明らかにする
  • 3.1. 「変更」に耳を傾ける
  • 3.2. Open/Closed原則から始めよ
  • 3.3. コードの匂いに気づくには
  • 3.4. 敵の弱点を見つける
  • 3.5. 体系的にリファクタリングする
  • 3.6. Flocking（群れをなす）ルールに従う
  • 3.7. 抽象に変換する
    • 3.7.1. 違いに着目する
    • 3.7.2. 難問をシンプルな問題に変える
    • 3.7.3. ネーミングのコンセプト
    • 3.7.4. 変化を秩序立てる
    • 3.7.5. 段階的にリファクタリングする
  • 3.8. まとめ
• 4. 「水平リファクタリング」の実践
  • 4.1. 「違い」を「同じもの」に置き換える
  • 4.2. ネーミングのごまかし
  • 4.3. 責務に沿って名前をつける
  • 4.4. 意味のあるデフォルトを選ぶ
  • 4.5. 安定した着地点を見つける
  • 4.6. リスコフの置換原則に従う
  • 4.7. 進捗の歩幅を広げる
  • 4.8. さらに高い抽象を発見する
  • 4.9. 抽象化への依存
  • 4.10. まとめ
• 5. 責務の分割
  • 5.1. 退治する「コードの匂い」を決める
    • 5.1.1. コードからパターンを見い出す
    • 5.1.2. 「共通の品質」に着目する
    • 5.1.3. Flock化したメソッドの共通点を列挙する
    • 5.1.4. 「メッセージ」にこだわる
  • 5.2. クラスに切り出す
    • 5.2.1. 抽象をモデリングする
    • 5.2.2. クラスに名前をつける
    • 5.2.3. 「BottleNumber」を切り出す
    • 5.2.4. 引数を取り除く
    • 5.2.5. プロセスを信頼できるものにする
  • 5.3. イミュータブルの重要性を理解する
  • 5.4. 十分な高速さを仮定する
  • 5.5. 「BottleNumbers」を作成する
  • 5.6. リスコフの置換原則の違反を見つけ出す
  • 5.7. まとめ
• 6. 「オープン」を達成する
  • 6.1. データを地固めする
  • 6.2. 条件文の感覚を養う
  • 6.3. 条件文をポリモーフィズムに置き換える
    • 6.3.1. 条件文を分解する
    • 6.3.2. オブジェクトをこしらえる
    • 6.3.3. ポリモーフィズムを広める
    • 6.3.4. 条件文で和平をもたらす
  • 6.4. 型の移り変わり
  • 6.5. 変更を楽にできるようにする
  • 6.6. ドメインを保護する
  • 6.7. Factoryをこじ開ける
  • 6.8. まとめ