1. 抽象的な名前よりも具体的な名前を使う
2. リーダブルコード
2.1. 理解しやすいコード
2.1.1. コードは他人が最短時間で理解できる様に！
2.1.1.1. 「他人」とは数ヶ月後の自分も入っている
2.1.1.2. コードが短ければ良い。という訳ではない
2.1.1.3. 必要ならコメントをつけて理解しやすくする
2.1.1.4. 読みやすいコードか常に自問自答することが大事
2.2. 名前に情報をつめこむ
2.2.1. 変数・関数・クラスなどの名前を短いコメントと考える
2.2.1.1. 名前の付け方
2.2.1.1.1. 明確な単語を選ぶ
2.2.1.1.2. 汎用的な名前を避ける
2.2.1.1.3. 重要な情報は名前に追加する
2.2.1.1.4. 名前の長さを決める
2.2.1.1.5. 名前のフォーマットで情報を伝える
2.3. 誤解されない名前
2.3.1. 名前が他の意味と間違われる事はないだろうか？
2.3.1.1. 解決策
2.3.1.1.1. 限界値がある時
2.3.1.1.2. 範囲を指定する時
2.3.1.1.3. ブール値の名前
2.3.1.1.4. ユーザーの期待に合わせる
2.3.1.1.5. 複数の名前を検討する
2.3.2. 自問自答を繰り返して、変更が必要な曖昧な表現を見つける
2.4. コードの美しさ
2.4.1. ３つの原則
2.4.1.1. 一貫性のあるレイアウト
2.4.1.2. 似ているコードは、シルエットも似ているように見せる（ぱっと見てわかるように）
2.4.1.3. 関連するコードはまとめてブロックにする
2.4.2. 解決策
2.4.2.1. 一貫性のある簡潔な改行位置
2.4.2.2. 縦の先を真っ直ぐにする
2.4.2.3. 意味のある並び(アルファベット順、重要度など)にする
2.4.2.4. 宣言やコードを論理的なグループにまとめる
2.4.2.5. 個人的な好みよりもプロジェクトの規約に従う
2.5. コメント
2.5.1. コメントすべきことを知る
2.5.1.1. コメントの目的は書き手の意図を読み手に知らせること
2.5.1.2. コメントを書く時に注意する事
2.5.1.2.1. コメントすべきではないことを知る
2.5.1.2.2. コードを書いている時の自分の考えを記録する
2.5.1.2.3. 読み手の立場になって必要な情報を考える
2.5.2. コメントは正確で簡潔に
2.5.2.1. コメントは領域に対する情報の比率が高くなければならない
2.5.2.1.1. コメントを簡潔にする
2.5.2.1.2. あいまいな代名詞は避ける(主語を明確に)
2.5.2.1.3. 歯切れの悪い文章は書かない
2.5.2.1.4. 関数の動作を正確に記述する
2.5.2.1.5. 入出力のコーナーケースに実例を使う(正確なコメントが難しい場合)
2.5.2.1.6. コードの意図を書く
2.5.2.1.7. 情報密度の高い言葉を使う(知識・経験が必要)
2.6. 制御フローを読みやすくする
2.6.1. 条件やループなどの制御フローはできるだけ自然に
2.6.2. コードの読み手が立ち止まったり読み返したりしない様に
2.6.3. 方法
2.6.3.1. 条件式の引数の並び順
2.6.3.1.1. 左側：「調査対象」の式=>変化する
2.6.3.1.2. 右側：「比較対象」の式=>あまり変化しない
2.6.3.2. if/elseブロックの並び順
2.6.3.2.1. 条件は否定形よりも肯定形で書く
2.6.3.2.2. 単純な条件を先に書く
2.6.3.2.3. 関心を引く条件を先に書く
2.6.3.2.4. ※優先度を自分で判断する必要がある
2.6.3.3. 三項演算子、gotoなどの使い方
2.6.3.3.1. 使っても良いが、読みやすさ重視
2.6.3.4. ネストを浅くする
2.7. 巨大な式を分割する
2.7.1. 巨大な式は理解しやすい大きさに分割する
2.7.1.1. 説明変数
2.7.1.1.1. 読みにくいコードは変数を作って説明する
2.7.1.2. 要約変数
2.7.1.2.1. 式を説明する必要がない場合でも、式を変数に代入しておくと便利
2.7.1.2.2. 大きなコードの塊を小さな名前に置き換えて、管理や把握を簡単にする
2.7.1.3. 「頭の良い」コードに気を付ける
2.7.1.3.1. １行にまとめて書くよりも、複数行に分割して書いたほうが何がしたいのかわかりやすい
2.7.1.4. より単純で優雅な手法を見つける
2.7.1.4.1. ロジックを正しく理解することが大切
2.7.1.5. 巨大な文を分割する
2.8. 変数と読みやすさ
2.8.1. 変数を適当に使うとプログラムが理解しにくくなる
2.8.2. ３つの問題
2.8.2.1. 変数が多いと変数を追うのが難しくなる
2.8.2.1.1. 変数を削除する
2.8.2.2. 変数のスコープが大きいとスコープを把握する時間が長くなる
2.8.2.2.1. 変数のスコープを縮める
2.8.2.3. 変数が頻繁に変更されると現在の値を把握するのが難しくなる
2.8.2.3.1. 変数は一度だけ書き込む
2.9. コードの再構成
2.9.1. 「無関係の下位問題」を積極的に抽出する
2.9.1.1. 関数は小さく・独立したものにする
2.9.1.2. プロジェクト固有のコードから汎用コードを分離する
2.9.2. コードを再構築して一度に１つの事をやる様にする
2.9.2.1. コードがやっているタスクを整理して、分割する
2.9.3. 最初にコードを言葉で説明する
2.9.3.1. コードの動作を簡単な言葉で同僚にもわかるように説明する
2.9.3.2. コードも簡単な言葉で書く
2.9.4. 短いコードを書く
2.9.4.1. 最も読みやすいコードは何も書かれていないコード
2.9.4.1.1. できるだけコードを書かない
3. オブジェクト指向設計実践ガイド
3.1. 単一責任クラス
3.1.1. 隠蔽されていた性質を明らかにする
3.1.2. コメントする必要がない
3.1.3. 再利用を促進する
3.1.4. ほかのクラスへの移動がかんたん
3.2. 依存関係の管理
3.2.1. 自身より変更されないものに依存する
3.2.1.1. 具象クラスは抽象クラスよりも変わる可能性が高い
3.2.1.2. 依存が増えると影響範囲が増える
3.3. 柔軟なインターフェースをつくる
3.3.1. 明示的なインターフェース
3.3.2. 「どのように」よりも「何を」
3.3.3. 名前は変わり得ないもの
3.4. ダックタイピング
3.4.1. 具象的なコードは理解は簡単だが、拡張しづらい
3.4.2. 抽象的なコードは最初分かりにくいが、一度理解してしまえば、変更や拡張がしやすい
3.4.3. 動的型付けでのみ可能な特有の手法
3.4.3.1. 型エラーを防ぐのはプログラマーの力
3.4.3.2. コードの良さはテストの良さ
3.4.4. オブジェクトが何であるかではなく、何をするか
3.5. 継承
3.5.1. 抽象クラスはサブクラスのために存在する（唯一の目的）
3.5.2. Rubyは他者信頼の性質をもつので、抽象クラスのインスタンスを作成することへの制約がない
3.5.2.1. ほかのプログラマがインスタンスを作ることを防げるのは、「良識」だけ
3.5.3. リスコフの置換原則
3.5.3.1. スーパークラスとサブクラスは入れ替え可能でなければならない
3.5.4. テンプレートメソッドパターン
3.5.4.1. 抽象クラスで振る舞いのデフォルトの挙動を定義
3.5.4.2. 具象クラスでそのメソッドに手を加えたりする
3.5.4.3. サブクラス特有の処理が区別できる
3.5.5. superはできるだけ使わない
3.5.5.1. 具象と抽象の依存を減らす
3.5.6. フックメソッド
3.5.6.1. 継承者がスーパークラスに特化を提供できるようにする
3.5.6.2. 抽象的なアルゴリズムを知らなくともサブクラスは専門性を加えられる
3.5.7. 継承の強みは、拡張の容易さ
3.6. モジュール化
3.6.1. 役割（ロール）で振る舞いを抽象
3.6.2. 抽象クラスを継承したらサブクラスでは必ずコードを利用する。モジュールも同様
3.7. コンポジション
3.7.1. ＝オブジェクトの組み合わせ
3.7.2. 複数のオブジェクトをhas-aの関係で組み合わせる
3.7.3. コンポジション ＞ 継承
3.8. まとめ
3.8.1. 継承
3.8.1.1. 将来の要件変更が少ない場合
3.8.1.2. オブジェクト同士がis-aの関係を持つ場合
3.8.2. コンポジション
3.8.2.1. クラスが複数のパーツから構成される場合
3.8.2.2. オブジェクト同士がhas-aの関係の場合
3.8.3. ダックタイピング
3.8.3.1. 関連しないオブジェクト同士にも同じ振る舞いを持たせたい場合
3.8.3.2. behaves-like-aの関係
3.8.3.3. クラスの責務として適当ではない振る舞いの場合