Download as PDF, PPTX
![2種類の複雑さ
● 単一のコンポーネントに内包される複雑さ
○ 1つのエンティティ、1つのクラス、1つのfunctionに複数の責務・概念が混ざっている。単
一責任原則(SRP)に違反した状態
○ Unknown Unknowns (理解困難) [A Philosophy of Software Design]
● コンポーネント数が多いことによる複雑さ
○ エンティティやクラス、 functionの数が多く、それぞれの役割や関係性を理解するのが厄
介。
○ 認知負荷が高い (把握難しい) [A Philosophy of Software Design]](https://image.slidesharecdn.com/whatisnsb-230616050136-0ab30cf0/85/slide-19-320.jpg)
![抽象化に必要なこと
type Suit = "Club" | "Diamond" | "Spade" | "Heart"
type Rank = "2" | "3" | "4" | "5" | "6" | "7" | "8"
| "9" | "10" | "Jack" | "Queen" | "King"
type Card = [ Suit, Rank ]
type Hand = Card[]
type Deck = Card[]
type Player = { name: string; hand: Hand }
type Game = { deck: Deck; players: Player[] }
type Deal = (deck:Deck) => [ Deck, Card ]
type PickupCard = (hand: Hand, card: Card) => Hand
前回のアーキ部
『Domain Modling Made Functional』の手法で本質的な状態とロジック を記述する
のがオススメ。日本語訳に期待！](https://image.slidesharecdn.com/whatisnsb-230616050136-0ab30cf0/85/slide-28-320.jpg)
ブルックスのいう銀の弾丸とは何か?
- 1.
- 2. “生産性、信頼性、簡便性において、10年以内に1桁の向上を 約束するような技術や経営手法の開発は、一つもない” Frederick P. Brooks MythicalMan-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition Chapter 16 No Silver Bullet—Essence and Accident in Software Engineering
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9. 後続の研究 Out of theTar Pit ※「人月の神話」の1章のタイトルがタールピットであることを踏まえている ”複雑さ、適合性、変更可能性、不可視性の4つの特性のうち、私たちは複 雑さが唯一の重要なものであると考えている。他の特性は、複雑さの形態 として分類されるか、またはシステムの複雑さのために問題が発生するた めに問題があると見なされる可能性がある。” https://curtclifton.net/papers/MoseleyMarks06a.pdf
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17. シンプルの対義語としての「複雑」 ● 1つの役割 ● 1つのタスク ●1つの概念 ● 複数の役割 ● 複数のタスク ● 複数の概念 シンプル 複雑 https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md
- 18.
- 19. 2種類の複雑さ ● 単一のコンポーネントに内包される複雑さ ○ 1つのエンティティ、1つのクラス、1つのfunctionに複数の責務・概念が混ざっている。単 一責任原則(SRP)に違反した状態 ○Unknown Unknowns (理解困難) [A Philosophy of Software Design] ● コンポーネント数が多いことによる複雑さ ○ エンティティやクラス、 functionの数が多く、それぞれの役割や関係性を理解するのが厄 介。 ○ 認知負荷が高い (把握難しい) [A Philosophy of Software Design]
- 20.
- 21.
- 22.
- 23. まず目指すべきは: 1つのエンティティに含まれる複雑さを最小化すること ● ドメインに含まれる責務・概念を可 視化する ● 理解のためであり、実装はそれか ら考えれば良い。 ●変更容易性は「理解しやすさ」の結 果であり、設計の第一目的ではな い
- 24.
- 25.
- 26.
- 27.
- 28. 抽象化に必要なこと type Suit ="Club" | "Diamond" | "Spade" | "Heart" type Rank = "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "10" | "Jack" | "Queen" | "King" type Card = [ Suit, Rank ] type Hand = Card[] type Deck = Card[] type Player = { name: string; hand: Hand } type Game = { deck: Deck; players: Player[] } type Deal = (deck:Deck) => [ Deck, Card ] type PickupCard = (hand: Hand, card: Card) => Hand 前回のアーキ部 『Domain Modling Made Functional』の手法で本質的な状態とロジック を記述する のがオススメ。日本語訳に期待！