Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à 世界最強のソフトウェアアーキテクト
Similaire à 世界最強のソフトウェアアーキテクト (20)
Plus de Yahoo!デベロッパーネットワーク
Plus de Yahoo!デベロッパーネットワーク (20)
Dernier
Dernier (7)
世界最強のソフトウェアアーキテクト
- 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