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