Downloaded 118 times
![メンタルモデルをコードで表現する
• ショッピングカートの例
A. $_SESSION[‘cart’][$item->getId()]+=$num;
B. $cart->addItem($item, $num);
• 剥き出しの実装にインターフェイスを被せる
• オブジェクト指向プログラミングの本質
• 具体的な実装はカプセル化
24](https://image.slidesharecdn.com/software-architect-study-150302232602-conversion-gate01/75/slide-24-2048.jpg)
![Facebook PHP SDK
• $fb = new Facebook([
'app_id' => '{app-id}',
'app_secret' => '{app-secret}',
]);
• $response = $fb->get('/me', '{token}');
• $me = $response->getGraphUser();
• echo $me->getName();
27](https://image.slidesharecdn.com/software-architect-study-150302232602-conversion-gate01/75/slide-27-2048.jpg)
More Related Content
世界最強のソフトウェアアーキテクト
- 1.
- 2. 小川 雄大 （おがわ かつひろ） ソーシャルマーケティング開発部 著書 パーフェクトPHP 効率的なWebアプリケーションの作り方 2 アシアル(2008) - クロコス(2011) - ヤフー(2014)
- 3. – ソフトウェアアーキテクチャ -Wikipedia “ソフトウェアアーキテクチャ（Software Architecture）は、ソフトウェアコンポーネント、 それらの外部特性、またそれらの相互関係から構 成される。” 3
- 4. – IEEE 1471- Wikipedia “アーキテクト（仕組士）: システムのアーキテクチャを設計する責任がある、 人、チーム、あるいは組織” 4
- 5. 対象者 • コードの質を高めたいと思っている人 • 設計に興味を持っている人 •設計がうまくいかず悩んでいる人 • 効率的にコードを書きたいと思っている人 • 開発現場に秩序をもたらしたい人 5
- 6.
- 7. アジェンダ 1. 技術的負債 2. メンタルモデルとオブジェクト指向設計 3.設計原則とパターン 4. アーキテクトのメンタル 7
- 8.
- 9.
- 10.
- 11.
- 12. 理解しづらいコード • 変更したい箇所で何やってるかわからなくて どう変えていいかわからない… • どこを変えればいいかすらわからない… •機能追加したら思わぬバグがでた… 12
- 13.
- 14. 古くなったライブラリ • サポート期限きれた… • 使いたい機能が使えない… •放置しすぎてもはやバージョンアップ できない… 14
- 15.
- 16. 技術的負債を駆逐する • コードを書く以上は発生し続ける負債 • 負債を完全になくすのは不可能 •コードを破棄するほかない 16
- 17. 技術的負債を駆逐する • 新たにコードが発生する際に負債に なりにくいよう設計する • 時が経ち古くなったコードを継続的に 改修していく •設計の知識、テクニック、経験が要求される 17
- 18. 組織として取り組んでいく • 企業・チームで開発をする以上、 個人だけの問題ではない • 規約やガイドラインを制定して ルール・知見を共有し秩序をもたらす •コードレビューを実施して品質向上と共に チーム全体の技術向上を図る 18
- 19.
- 20. 技術的資産 • ライブラリ・フレームワーク化 • 統一・洗練された思想やインターフェイス •整理されたドキュメント • それらをオープンソース化して 業界のイニシアチブをとる 20
- 21.
- 22. – メンタルモデル -Wikipedia “メンタルモデル（英: mental model）とは、 人間が実世界で何かがどのように作用するかを 思考する際のプロセスを表現したものである。” 22
- 23. メンタルモデル • 思考のプロセスを表現したもの • 利用者がどのように考えてシステムを 利用するか •プロダクトオーナーがどのような仕様に したいと考えているか • 開発者の抱く実装イメージ 23
- 24. メンタルモデルをコードで表現する • ショッピングカートの例 A. $_SESSION[‘cart’][$item->getId()]+=$num; B.$cart->addItem($item, $num); • 剥き出しの実装にインターフェイスを被せる • オブジェクト指向プログラミングの本質 • 具体的な実装はカプセル化 24
- 25.
- 26. ショッピングカートのユースケース • ユースケース • カートに商品を追加できる •カートに商品を追加する際に個数を指定できる • インターフェイス • class Cart • public function addItem(Item $item, $num) 26
- 27. Facebook PHP SDK •$fb = new Facebook([ 'app_id' => '{app-id}', 'app_secret' => '{app-secret}', ]); • $response = $fb->get('/me', '{token}'); • $me = $response->getGraphUser(); • echo $me->getName(); 27
- 28. – Trygve Reenskaug (TheDCI Architecture: A New Vision of Object-Oriented Programming) “MVC is about people and their mental models —not the Observer pattern” 28
- 29. チームにおける認識の共有 • 仕様についてチーム内で話し合うときに、 固有名詞やその意味を共通化する • ユーザー？アカウント？利用者？ •ユビキタス言語 • “共有されたチームの言語” 29
- 30.
- 31. 本質的な複雑さは単純に • メンタルモデルに沿って設計を進めることで インターフェイスが洗練される • コードが理解しやすくなり、修正や拡張も 行いやすくなる •シンプルに、文章のようなコーディングを 31
- 32. 難しいところ • 実現するためにはオブジェクト指向設計の ノウハウや経験が求められる • メンタルモデルを的確に捉え、コード上に 表現しつつ、複雑な実装の裏側はカプセル化 する、ということは簡単なことではない •シンプルがゆえに「これが普通」だと捉えら れるかも 32
- 33.
- 34. 設計の原則/パターン • 原則やパターンは開発における基礎知識 • 原則は負債を生み出しにくくするために •パターンは負債を取り除くために 34
- 35. パターンの乱用による弊害 • ただし乱用すると却って複雑に • “本質的な複雑さは単純に、 付随的な複雑さは取り除け” •常に本質的な問題の解決を意識し優先する 35
- 36.
- 37.
- 38.
- 39. DDD • ドメイン駆動設計 (DomainDriven Design) • 本質的な問題解決をするためのパターン集 39
- 40.
- 41. PofEAA • エンタープライズアプリケーション アーキテクチャパターン (Patterns ofEnterprise Application Architecture) • アーキテクチャパターン集 41
- 42.
- 43.
- 44.
- 45. DCI • Data ContextInteraction • データ、コンテキスト、相互作用 • MVCのようにメンタルモデルを表現する手法 • MVCの考案者らによる提案 45
- 46. さまざまな役割 • Controller • Entity •Repository • Service • Usecase • Api 46
- 47.
- 48.
- 49. DRY • Don’t RepeatYourself • 重複してはならない 49
- 50. SOLID • オブジェクト指向設計の5つ原則の頭文字 • 単一責任の原則 (SRP: Single Responsibility Principle) • オープン・クローズドの原則 (OCP : Open Closed Principle) • リスコフの置換原則 (LSP : Liscov Substitution Principle) • インターフェイス分離の原則 (ISP : Interface Segregation Principle) • 依存性逆転の原則 (DIP : Dependency Inversion Principle) 50
- 51. 単一責任の原則 (SRP) • "クラスを変更する理由は1つでなければ ならない" •クラスの責任は1つにして複雑化などを防ぐ 51
- 52. オープン・クローズドの原則 (OCP) • "拡張に対して開いていて、修正に対して 閉じていなければならない" •既存のコードに手を入れることなく 修正・拡張できるようにする 52
- 53. リスコフの置換原則 (LIP) • "派生型は基本型と置き換え可能でなければ ならない" •継承によって親クラスの実装を全く別のもの に変えてしまうのは間違った継承である 53
- 54. インターフェイス分離の原則 (ISP) • "クライアントに、クライアントが利用しない メソッドへの依存を強制してはならない" •利用するクライアントの視点から インターフェイスを定義しよう 54
- 55. 依存関係逆転の原則 (DIP) • "上位モジュールは下位モジュールに依存してはな らない。どちらも「抽象」に依存するべきである" •"「抽象」は実装の詳細に依存してはならない。 実装の詳細が「抽象」に依存すべきである。" • 実装からインターフェイスを抜き出すのではな く、要求に応じてインターフェイスを定義し、イ ンターフェイスにあわせて実装する 55
- 56.
- 57.
- 58. YAGNI • You Ain'tGonna Need It! • 実際に必要になるまで機能追加しない • “本質的な複雑さは単純に、 付随的な複雑さは取り除け” 58
- 59.
- 60. 経験は必要不可欠 • 失敗を恐れずに、「やってはいけないこと」 を身をもって覚える • 書いたコードを振り返り、よりよくなるには どうしたらようかを考える •そうして経験値として積み重ねたものが アーキテクトの支えになる 60
- 61.
- 62.
- 63.
- 64.
- 65.