SlideShare a Scribd company logo
Code Retreatの心得

Kazuki Murahama
2012-10-09
シンプルな設計のための4つのルール
OOの原則(SOLID)
オブジェクト健康体操
ペアプログラミングとコミュニケーション
ピンポンペア
シンプルな設計のための4つのルール

1. PASS ALL TESTS
   すべてをテストをパスする
2. CLEAR, EXPRESSIVE, & CONSISTENT
   きれいで、分かりやすく、一貫性があること
3. DUPLICATES NO BEHAVIOR OR CONFIGURATION
   重複はだめ
4. MINIMAL METHODS, CLASSES, & MODULES
   関数やクラス、モジュールは小さく
OOの原則(SOLID)オブジェクト指向設計原則

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

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


 変更理由が2つあるということは、責任(役割)も2つある。
   役割を複数もつクラスはもろい
   複数の役割がある場合、一つの変更に対する影響が大きい
   保守で違う人が修正したら簡単に壊れる
   クラスは密度が濃くて固いのが一番
   1クラス1責任、ピュアであること
   責任を見極めるには、”変更理由の観点から眺める”
   TDDによりかなり早い段階でSRP違反を発見できる
OOの原則(SOLID)オブジェクト指向設計原則

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

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


 拡張しやすく、修正による影響が少ない
   この原則はオブジェクト指向設計の核心(柔軟性、再利用性、保守性)
   事前に抽象クラスを用意する
   使う側に影響を与えてはいけない
   例
OOの原則(SOLID)オブジェクト指向設計原則

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

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


 派生クラスがその基本クラスで使われるところにおいても、正常に動作することを保証しなけ
 ればならない。
   例 : http://d.hatena.ne.jp/asakichy/20090127/1233109959
OOの原則(SOLID)オブジェクト指向設計原則

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

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

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


 OOプログラミングでは「方針」「詳細」とも抽象に依存させることで、悪しき依存関係を逆転で
 きる。
 アプリケーションの方針を決めていて、他に対して影響を与えるモジュール(=言うなれば「偉
 い」ヒト)は上位。
 それにより抽象と実装の詳細は完全に切り離され、コードの保守がずっと楽になる。
 例 : http://d.hatena.ne.jp/asakichy/20090128/1233144989
OOの原則(SOLID)オブジェクト指向設計原則

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

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


 クライアントは複数のインターフェイスを利用するけど、そのすべてが互いに強い関連を持っ
 ているわけではない。
 関連性持ったインターフェイスはグループ化して、抽象基本クラスとして分けて利用すべき。
 例 : http://d.hatena.ne.jp/asakichy/20090129/1233236193
心からのTDD

 失敗するテストを書く
 できる限り早く、テストがパスするような最小限のコード本体を書く
 コードの重複を除去する(リファクタリング)
オブジェクト健康体操

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

   ルール1:インデント1段階
     1つのメソッドにつきインデントは1段階までにすること
   ルール2:else句禁止
     else句を使用しないこと
   ルール3:プリミティブ禁止
     すべてのプリミティブ型と文字列型をラップすること
   ルール4:ドット1つ
     1行につきドットは1つまでにすること
オブジェクト健康体操

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

   ルール5:名前省略禁止
     名前を省略しないこと
   ルール6:小エンティティ
     すべてのエンティティを小さくすること
   ルール7:インスタンス変数2つ
     1つのクラスにつきインスタンス変数は2つまでにすること
   ルール8:ファーストクラスコレクション
     ファーストクラスコレクションを使用すること
   ルール9:プロパティ禁止
     Getter/Setter/プロパティを使用しないこと
ペアプログラミングとコミュニケーション

 ペアプログラミング実践動画
 http://www.youtube.com/embed/dYBjVTMUQY0
 二人でひとつのキーボードでプログラミングを行う
 一人がコーディング(driver)、一人が書かれるコードを眺めエラーや設計を吟味する
 (observer/navigator)
 ペアプログラミングやりかた
 http://p.tl/bC1h-
ピンポンペア

1.   Aさんがテストを書いて、失敗するのを確かめる
2.   Bさんがテストを合格するための実装を行う
3.   今度はBさんが次のテストを書き、失敗するのを確かめる
4.   Aさんが次のテストを合格するための実装を行う
参考文献

 Global Day Coderetreat
 http://p.tl/jSbD-
 オブジェクト指向設計原則
 http://d.hatena.ne.jp/asakichy/20090122/1232879842
 ペアプログラミングのやりかた
 http://p.tl/bC1h-
Code retreatの心得

More Related Content

More from Kazuki Murahama

2022_08_10 SaaS.tech #5業務システム開発でデザインとフロントエンドも妥協しない話
2022_08_10 SaaS.tech #5業務システム開発でデザインとフロントエンドも妥協しない話2022_08_10 SaaS.tech #5業務システム開発でデザインとフロントエンドも妥協しない話
2022_08_10 SaaS.tech #5業務システム開発でデザインとフロントエンドも妥協しない話Kazuki Murahama
 
kintoneの新機能、Webhookを使って社内システムをもっとインテグレートする #2 SmartTechGeeks
kintoneの新機能、Webhookを使って社内システムをもっとインテグレートする #2 SmartTechGeekskintoneの新機能、Webhookを使って社内システムをもっとインテグレートする #2 SmartTechGeeks
kintoneの新機能、Webhookを使って社内システムをもっとインテグレートする #2 SmartTechGeeksKazuki Murahama
 
kintone x AWSで超ファストシステムを作ろう 〜 AWSでkintone APIをよりよく使う〜
kintone x AWSで超ファストシステムを作ろう 〜 AWSでkintone APIをよりよく使う〜kintone x AWSで超ファストシステムを作ろう 〜 AWSでkintone APIをよりよく使う〜
kintone x AWSで超ファストシステムを作ろう 〜 AWSでkintone APIをよりよく使う〜Kazuki Murahama
 
継続的目標達成メソッド
継続的目標達成メソッド継続的目標達成メソッド
継続的目標達成メソッドKazuki Murahama
 
Kintoneでエンジニアが納得のいく社内システムをつくる
Kintoneでエンジニアが納得のいく社内システムをつくるKintoneでエンジニアが納得のいく社内システムをつくる
Kintoneでエンジニアが納得のいく社内システムをつくるKazuki Murahama
 
Okinawa frontend meetup1_俺のフロントエンド開発がこんなに時代おくれなワケがない
Okinawa frontend meetup1_俺のフロントエンド開発がこんなに時代おくれなワケがないOkinawa frontend meetup1_俺のフロントエンド開発がこんなに時代おくれなワケがない
Okinawa frontend meetup1_俺のフロントエンド開発がこんなに時代おくれなワケがないKazuki Murahama
 
【社内勉強会】Docker入門
【社内勉強会】Docker入門【社内勉強会】Docker入門
【社内勉強会】Docker入門Kazuki Murahama
 
Xhago3_network_no_immade
Xhago3_network_no_immadeXhago3_network_no_immade
Xhago3_network_no_immadeKazuki Murahama
 

More from Kazuki Murahama (10)

2022_08_10 SaaS.tech #5業務システム開発でデザインとフロントエンドも妥協しない話
2022_08_10 SaaS.tech #5業務システム開発でデザインとフロントエンドも妥協しない話2022_08_10 SaaS.tech #5業務システム開発でデザインとフロントエンドも妥協しない話
2022_08_10 SaaS.tech #5業務システム開発でデザインとフロントエンドも妥協しない話
 
kintoneの新機能、Webhookを使って社内システムをもっとインテグレートする #2 SmartTechGeeks
kintoneの新機能、Webhookを使って社内システムをもっとインテグレートする #2 SmartTechGeekskintoneの新機能、Webhookを使って社内システムをもっとインテグレートする #2 SmartTechGeeks
kintoneの新機能、Webhookを使って社内システムをもっとインテグレートする #2 SmartTechGeeks
 
kintone x AWSで超ファストシステムを作ろう 〜 AWSでkintone APIをよりよく使う〜
kintone x AWSで超ファストシステムを作ろう 〜 AWSでkintone APIをよりよく使う〜kintone x AWSで超ファストシステムを作ろう 〜 AWSでkintone APIをよりよく使う〜
kintone x AWSで超ファストシステムを作ろう 〜 AWSでkintone APIをよりよく使う〜
 
継続的目標達成メソッド
継続的目標達成メソッド継続的目標達成メソッド
継続的目標達成メソッド
 
Kintoneでエンジニアが納得のいく社内システムをつくる
Kintoneでエンジニアが納得のいく社内システムをつくるKintoneでエンジニアが納得のいく社内システムをつくる
Kintoneでエンジニアが納得のいく社内システムをつくる
 
Okinawa frontend meetup1_俺のフロントエンド開発がこんなに時代おくれなワケがない
Okinawa frontend meetup1_俺のフロントエンド開発がこんなに時代おくれなワケがないOkinawa frontend meetup1_俺のフロントエンド開発がこんなに時代おくれなワケがない
Okinawa frontend meetup1_俺のフロントエンド開発がこんなに時代おくれなワケがない
 
攻める情シス
攻める情シス攻める情シス
攻める情シス
 
【社内勉強会】Docker入門
【社内勉強会】Docker入門【社内勉強会】Docker入門
【社内勉強会】Docker入門
 
Munin入れてみた
Munin入れてみたMunin入れてみた
Munin入れてみた
 
Xhago3_network_no_immade
Xhago3_network_no_immadeXhago3_network_no_immade
Xhago3_network_no_immade
 

Code retreatの心得