Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 世界最強のソフトウェアアーキテクト
Similar to 世界最強のソフトウェアアーキテクト (20)
More from Yahoo!デベロッパーネットワーク
More from Yahoo!デベロッパーネットワーク (20)
Recently uploaded
Recently uploaded (11)
世界最強のソフトウェアアーキテクト
- 2. 小川 雄大 （おがわ かつひろ） ソーシャルマーケティング開発部 著書 パーフェクトPHP 効率的なWebアプリケーションの作り方 2 アシアル (2008) - クロコス(2011) - ヤフー(2014)
- 3. – ソフトウェアアーキテクチャ - Wikipedia “ソフトウェアアーキテクチャ（Software Architecture）は、ソフトウェアコンポーネント、 それらの外部特性、またそれらの相互関係から構 成される。” 3
- 4. – IEEE 1471 - Wikipedia “アーキテクト（仕組士）: システムのアーキテクチャを設計する責任がある、 人、チーム、あるいは組織” 4
- 5. 対象者 • コードの質を高めたいと思っている人 • 設計に興味を持っている人 • 設計がうまくいかず悩んでいる人 • 効率的にコードを書きたいと思っている人 • 開発現場に秩序をもたらしたい人 5
- 7. アジェンダ 1. 技術的負債 2. メンタルモデルとオブジェクト指向設計 3. 設計原則とパターン 4. アーキテクトのメンタル 7
- 8. 技術的負債 8
- 10. 技術的負債の例 10
- 12. 理解しづらいコード • 変更したい箇所で何やってるかわからなくて どう変えていいかわからない… • どこを変えればいいかすらわからない… • 機能追加したら思わぬバグがでた… 12
- 14. 古くなったライブラリ • サポート期限きれた… • 使いたい機能が使えない… • 放置しすぎてもはやバージョンアップ できない… 14
- 16. 技術的負債を駆逐する • コードを書く以上は発生し続ける負債 • 負債を完全になくすのは不可能 • コードを破棄するほかない 16
- 17. 技術的負債を駆逐する • 新たにコードが発生する際に負債に なりにくいよう設計する • 時が経ち古くなったコードを継続的に 改修していく • 設計の知識、テクニック、経験が要求される 17
- 18. 組織として取り組んでいく • 企業・チームで開発をする以上、 個人だけの問題ではない • 規約やガイドラインを制定して ルール・知見を共有し秩序をもたらす • コードレビューを実施して品質向上と共に チーム全体の技術向上を図る 18
- 20. 技術的資産 • ライブラリ・フレームワーク化 • 統一・洗練された思想やインターフェイス • 整理されたドキュメント • それらをオープンソース化して 業界のイニシアチブをとる 20
- 22. – メンタルモデル - Wikipedia “メンタルモデル（英: mental model）とは、 人間が実世界で何かがどのように作用するかを 思考する際のプロセスを表現したものである。” 22
- 23. メンタルモデル • 思考のプロセスを表現したもの • 利用者がどのように考えてシステムを 利用するか • プロダクトオーナーがどのような仕様に したいと考えているか • 開発者の抱く実装イメージ 23
- 24. メンタルモデルをコードで表現する • ショッピングカートの例 A. $_SESSION[‘cart’][$item->getId()]+=$num; B. $cart->addItem($item, $num); • 剥き出しの実装にインターフェイスを被せる • オブジェクト指向プログラミングの本質 • 具体的な実装はカプセル化 24
- 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 (The DCI Architecture: A New Vision of Object-Oriented Programming) “MVC is about people and their mental models —not the Observer pattern” 28
- 29. チームにおける認識の共有 • 仕様についてチーム内で話し合うときに、 固有名詞やその意味を共通化する • ユーザー？アカウント？利用者？ • ユビキタス言語 • “共有されたチームの言語” 29
- 31. 本質的な複雑さは単純に • メンタルモデルに沿って設計を進めることで インターフェイスが洗練される • コードが理解しやすくなり、修正や拡張も 行いやすくなる • シンプルに、文章のようなコーディングを 31
- 32. 難しいところ • 実現するためにはオブジェクト指向設計の ノウハウや経験が求められる • メンタルモデルを的確に捉え、コード上に 表現しつつ、複雑な実装の裏側はカプセル化 する、ということは簡単なことではない • シンプルがゆえに「これが普通」だと捉えら れるかも 32
- 33. 設計原則とパターン 33
- 34. 設計の原則/パターン • 原則やパターンは開発における基礎知識 • 原則は負債を生み出しにくくするために • パターンは負債を取り除くために 34
- 35. パターンの乱用による弊害 • ただし乱用すると却って複雑に • “本質的な複雑さは単純に、 付随的な複雑さは取り除け” • 常に本質的な問題の解決を意識し優先する 35
- 36. パターン 36
- 37. パターンとは • 設計ノウハウに名称をつけて共有されたもの • 「こういった問題に対してはこのパターンを 適応することで解決できる」 • たくさんあるので詳細は省略 37
- 39. DDD • ドメイン駆動設計 (Domain Driven Design) • 本質的な問題解決をするためのパターン集 39
- 41. PofEAA • エンタープライズアプリケーション アーキテクチャパターン (Patterns of Enterprise Application Architecture) • アーキテクチャパターン集 41
- 45. DCI • Data Context Interaction • データ、コンテキスト、相互作用 • MVCのようにメンタルモデルを表現する手法 • MVCの考案者らによる提案 45
- 46. さまざまな役割 • Controller • Entity • Repository • Service • Usecase • Api 46
- 47. 原則 47
- 49. DRY • Don’t Repeat Yourself • 重複してはならない 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
- 58. YAGNI • You Ain't Gonna Need It! • 実際に必要になるまで機能追加しない • “本質的な複雑さは単純に、 付随的な複雑さは取り除け” 58
- 59. アーキテクトのメンタル 59
- 60. 経験は必要不可欠 • 失敗を恐れずに、「やってはいけないこと」 を身をもって覚える • 書いたコードを振り返り、よりよくなるには どうしたらようかを考える • そうして経験値として積み重ねたものが アーキテクトの支えになる 60
- 63. 責任を持つ • 修正や拡張を行う際にリスクを恐れて メンタルモデルにそぐわないコードを書くと 技術負債として重くのしかかる • リスクをとるか、負債をとるかは アーキテクトとして責任をもって判断する • 誰かが責任を持たないと全員が不幸になる 63