Code retreatの心得
- 3. シンプルな設計のための4つのルール 1. PASS ALL TESTS すべてをテストをパスする 2. CLEAR, EXPRESSIVE, & CONSISTENT きれいで、分かりやすく、一貫性があること 3. DUPLICATES NO BEHAVIOR OR CONFIGURATION 重複はだめ 4. MINIMAL METHODS, CLASSES, & MODULES 関数やクラス、モジュールは小さく
- 4. OOの原則(SOLID)オブジェクト指向設計原則 単一責任の原則（SRP:the Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない。 変更理由が2つあるということは、責任（役割）も2つある。 役割を複数もつクラスはもろい 複数の役割がある場合、一つの変更に対する影響が大きい 保守で違う人が修正したら簡単に壊れる クラスは密度が濃くて固いのが一番 1クラス1責任、ピュアであること 責任を見極めるには、”変更理由の観点から眺める” TDDによりかなり早い段階でSRP違反を発見できる
- 5. OOの原則(SOLID)オブジェクト指向設計原則 オープン・クローズドの原則（OCP:the Open-Closed Principle）（開放－閉鎖原則） ソフトウェアの構成要素は、拡張に対して開いていて、修正に対して閉じていなければならな い。 拡張しやすく、修正による影響が少ない この原則はオブジェクト指向設計の核心(柔軟性、再利用性、保守性) 事前に抽象クラスを用意する 使う側に影響を与えてはいけない 例
- 6. OOの原則(SOLID)オブジェクト指向設計原則 リスコフの置換原則（LSP:the Liskov Substitution Principle） 派生型はその基本型と置換可能でなければならない。 派生クラスがその基本クラスで使われるところにおいても、正常に動作することを保証しなけ ればならない。 例 : http://d.hatena.ne.jp/asakichy/20090127/1233109959
- 7. OOの原則(SOLID)オブジェクト指向設計原則 依存関係逆転の原則（DIP:the Dependency Inversion Principle） 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」 に依存すべきである。 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。 OOプログラミングでは「方針」「詳細」とも抽象に依存させることで、悪しき依存関係を逆転で きる。 アプリケーションの方針を決めていて、他に対して影響を与えるモジュール(＝言うなれば「偉 い」ヒト)は上位。 それにより抽象と実装の詳細は完全に切り離され、コードの保守がずっと楽になる。 例 : http://d.hatena.ne.jp/asakichy/20090128/1233144989
- 8. OOの原則(SOLID)オブジェクト指向設計原則 インターフェイス分離の原則（ISP:the Interface Segregation Principle） クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない。 クライアントは複数のインターフェイスを利用するけど、そのすべてが互いに強い関連を持っ ているわけではない。 関連性持ったインターフェイスはグループ化して、抽象基本クラスとして分けて利用すべき。 例 : http://d.hatena.ne.jp/asakichy/20090129/1233236193
- 9. 心からのTDD 失敗するテストを書く できる限り早く、テストがパスするような最小限のコード本体を書く コードの重複を除去する（リファクタリング）
- 10. オブジェクト健康体操 参考 : http://d.hatena.ne.jp/asakichy/20090612 ルール1：インデント１段階 1つのメソッドにつきインデントは1段階までにすること ルール2：else句禁止 else句を使用しないこと ルール3：プリミティブ禁止 すべてのプリミティブ型と文字列型をラップすること ルール4：ドット１つ 1行につきドットは1つまでにすること
- 11. オブジェクト健康体操 参考 : http://d.hatena.ne.jp/asakichy/20090612 ルール5：名前省略禁止 名前を省略しないこと ルール6：小エンティティ すべてのエンティティを小さくすること ルール7：インスタンス変数２つ 1つのクラスにつきインスタンス変数は2つまでにすること ルール8：ファーストクラスコレクション ファーストクラスコレクションを使用すること ルール9：プロパティ禁止 Getter/Setter/プロパティを使用しないこと
- 12. ペアプログラミングとコミュニケーション ペアプログラミング実践動画 http://www.youtube.com/embed/dYBjVTMUQY0 二人でひとつのキーボードでプログラミングを行う 一人がコーディング(driver)、一人が書かれるコードを眺めエラーや設計を吟味する (observer/navigator) ペアプログラミングやりかた http://p.tl/bC1h-
- 13. ピンポンペア 1. Aさんがテストを書いて、失敗するのを確かめる 2. Bさんがテストを合格するための実装を行う 3. 今度はBさんが次のテストを書き、失敗するのを確かめる 4. Aさんが次のテストを合格するための実装を行う
- 14. 参考文献 Global Day Coderetreat http://p.tl/jSbD- オブジェクト指向設計原則 http://d.hatena.ne.jp/asakichy/20090122/1232879842 ペアプログラミングのやりかた http://p.tl/bC1h-