code retreatの心得

15

Click here to load reader

Upload: kazuki-murahama

Post on 03-Jul-2015

1.752 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: Code retreatの心得

Code Retreatの心得

Kazuki Murahama

2012-10-09

Page 2: Code retreatの心得

シンプルな設計のための4つのルール

OOの原則(SOLID)

オブジェクト健康体操

ペアプログラミングとコミュニケーション

ピンポンペア

Page 3: Code retreatの心得

シンプルな設計のための4つのルール

1. PASS ALL TESTS

すべてをテストをパスする

2. CLEAR, EXPRESSIVE, & CONSISTENT

きれいで、分かりやすく、一貫性があること

3. DUPLICATES NO BEHAVIOR OR CONFIGURATION

重複はだめ

4. MINIMAL METHODS, CLASSES, & MODULES

関数やクラス、モジュールは小さく

Page 4: Code retreatの心得

OOの原則(SOLID)オブジェクト指向設計原則

単一責任の原則(SRP:the Single Responsibility Principle)

クラスを変更する理由は1つ以上存在してはならない。

変更理由が2つあるということは、責任(役割)も2つある。

役割を複数もつクラスはもろい

複数の役割がある場合、一つの変更に対する影響が大きい

保守で違う人が修正したら簡単に壊れる

クラスは密度が濃くて固いのが一番

1クラス1責任、ピュアであること

責任を見極めるには、”変更理由の観点から眺める”

TDDによりかなり早い段階でSRP違反を発見できる

Page 5: Code retreatの心得

OOの原則(SOLID)オブジェクト指向設計原則

オープン・クローズドの原則(OCP:the Open-Closed Principle)(開放-閉鎖原則)

ソフトウェアの構成要素は、拡張に対して開いていて、修正に対して閉じていなければならな

い。

拡張しやすく、修正による影響が少ない

この原則はオブジェクト指向設計の核心(柔軟性、再利用性、保守性)

事前に抽象クラスを用意する

使う側に影響を与えてはいけない

Page 6: Code retreatの心得

OOの原則(SOLID)オブジェクト指向設計原則

リスコフの置換原則(LSP:the Liskov Substitution Principle)

派生型はその基本型と置換可能でなければならない。

派生クラスがその基本クラスで使われるところにおいても、正常に動作することを保証しなけ

ればならない。

例 : http://d.hatena.ne.jp/asakichy/20090127/1233109959

Page 7: Code retreatの心得

OOの原則(SOLID)オブジェクト指向設計原則

依存関係逆転の原則(DIP:the Dependency Inversion Principle)

上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」

に依存すべきである。

「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。

OOプログラミングでは「方針」「詳細」とも抽象に依存させることで、悪しき依存関係を逆転で

きる。

アプリケーションの方針を決めていて、他に対して影響を与えるモジュール(=言うなれば「偉

い」ヒト)は上位。

それにより抽象と実装の詳細は完全に切り離され、コードの保守がずっと楽になる。

例 : http://d.hatena.ne.jp/asakichy/20090128/1233144989

Page 8: Code retreatの心得

OOの原則(SOLID)オブジェクト指向設計原則

インターフェイス分離の原則(ISP:the Interface Segregation Principle)

クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない。

クライアントは複数のインターフェイスを利用するけど、そのすべてが互いに強い関連を持っ

ているわけではない。

関連性持ったインターフェイスはグループ化して、抽象基本クラスとして分けて利用すべき。

例 : http://d.hatena.ne.jp/asakichy/20090129/1233236193

Page 9: Code retreatの心得

心からのTDD

失敗するテストを書く

できる限り早く、テストがパスするような最小限のコード本体を書く

コードの重複を除去する(リファクタリング)

Page 10: Code retreatの心得

オブジェクト健康体操

参考 : http://d.hatena.ne.jp/asakichy/20090612

ルール1:インデント1段階

1つのメソッドにつきインデントは1段階までにすること

ルール2:else句禁止

else句を使用しないこと

ルール3:プリミティブ禁止

すべてのプリミティブ型と文字列型をラップすること

ルール4:ドット1つ

1行につきドットは1つまでにすること

Page 11: Code retreatの心得

オブジェクト健康体操

参考 : http://d.hatena.ne.jp/asakichy/20090612

ルール5:名前省略禁止

名前を省略しないこと

ルール6:小エンティティ

すべてのエンティティを小さくすること

ルール7:インスタンス変数2つ

1つのクラスにつきインスタンス変数は2つまでにすること

ルール8:ファーストクラスコレクション

ファーストクラスコレクションを使用すること

ルール9:プロパティ禁止

Getter/Setter/プロパティを使用しないこと

Page 12: Code retreatの心得

ペアプログラミングとコミュニケーション

ペアプログラミング実践動画

http://www.youtube.com/embed/dYBjVTMUQY0

二人でひとつのキーボードでプログラミングを行う

一人がコーディング(driver)、一人が書かれるコードを眺めエラーや設計を吟味する

(observer/navigator)

ペアプログラミングやりかた

http://p.tl/bC1h-

Page 13: Code retreatの心得

ピンポンペア

1. Aさんがテストを書いて、失敗するのを確かめる

2. Bさんがテストを合格するための実装を行う

3. 今度はBさんが次のテストを書き、失敗するのを確かめる

4. Aさんが次のテストを合格するための実装を行う

Page 14: Code retreatの心得

参考文献

Global Day Coderetreat

http://p.tl/jSbD-

オブジェクト指向設計原則

http://d.hatena.ne.jp/asakichy/20090122/1232879842

ペアプログラミングのやりかた

http://p.tl/bC1h-

Page 15: Code retreatの心得