Submit Search
Upload
ソフトウェアにおける 複雑さとは何なのか?
•
3 likes
•
1,227 views
Yoshitaka Kawashima
Follow
アーキ部 #12 「複雑さ」について語り合う会 の参考資料です
Read less
Read more
Software
Report
Share
Report
Share
1 of 23
Download now
Download to read offline
Recommended
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
関数型・オブジェクト指向宗教戦争に疲れたなたに送るGo言語入門
関数型・オブジェクト指向宗教戦争に疲れたなたに送るGo言語入門
Tadahiro Ishisaka
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
私にとってのテスト
私にとってのテスト
Takuto Wada
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
Koichiro Matsuoka
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
Recommended
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
関数型・オブジェクト指向宗教戦争に疲れたなたに送るGo言語入門
関数型・オブジェクト指向宗教戦争に疲れたなたに送るGo言語入門
Tadahiro Ishisaka
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
私にとってのテスト
私にとってのテスト
Takuto Wada
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
Koichiro Matsuoka
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
Mikiya Okuno
例外設計における大罪
例外設計における大罪
Takuto Wada
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
yoku0825
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
リレーショナルな正しいデータベース設計
リレーショナルな正しいデータベース設計
Mikiya Okuno
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
Yoshitaka Kawashima
どこに何を書くのか?
どこに何を書くのか?
pospome
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Yoshitaka Kawashima
Are Design Patterns Dead?
Are Design Patterns Dead?
Yoshitaka Kawashima
More Related Content
What's hot
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
Mikiya Okuno
例外設計における大罪
例外設計における大罪
Takuto Wada
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
yoku0825
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
リレーショナルな正しいデータベース設計
リレーショナルな正しいデータベース設計
Mikiya Okuno
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
Yoshitaka Kawashima
どこに何を書くのか?
どこに何を書くのか?
pospome
What's hot
(20)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
例外設計における大罪
例外設計における大罪
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
Tackling Complexity
Tackling Complexity
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
Redisの特徴と活用方法について
Redisの特徴と活用方法について
リレーショナルな正しいデータベース設計
リレーショナルな正しいデータベース設計
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
PostgreSQLアンチパターン
PostgreSQLアンチパターン
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
どこに何を書くのか?
どこに何を書くのか?
More from Yoshitaka Kawashima
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Yoshitaka Kawashima
Are Design Patterns Dead?
Are Design Patterns Dead?
Yoshitaka Kawashima
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
Yoshitaka Kawashima
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
Yoshitaka Kawashima
本番障害に至る病
本番障害に至る病
Yoshitaka Kawashima
システムダウンのひみつ
システムダウンのひみつ
Yoshitaka Kawashima
Mavenの真実とウソ
Mavenの真実とウソ
Yoshitaka Kawashima
アンチフラジャイルの世界
アンチフラジャイルの世界
Yoshitaka Kawashima
Atomic Architecture
Atomic Architecture
Yoshitaka Kawashima
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
Yoshitaka Kawashima
How to find tech books
How to find tech books
Yoshitaka Kawashima
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
Yoshitaka Kawashima
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
Yoshitaka Kawashima
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
Yoshitaka Kawashima
Antifragile Clojure
Antifragile Clojure
Yoshitaka Kawashima
Boilerplate vs Magic
Boilerplate vs Magic
Yoshitaka Kawashima
既婚プログラマの時間捻出術
既婚プログラマの時間捻出術
Yoshitaka Kawashima
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Yoshitaka Kawashima
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
Yoshitaka Kawashima
More from Yoshitaka Kawashima
(20)
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Are Design Patterns Dead?
Are Design Patterns Dead?
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
本番障害に至る病
本番障害に至る病
システムダウンのひみつ
システムダウンのひみつ
Mavenの真実とウソ
Mavenの真実とウソ
アンチフラジャイルの世界
アンチフラジャイルの世界
Atomic Architecture
Atomic Architecture
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
How to find tech books
How to find tech books
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
Antifragile Clojure
Antifragile Clojure
Boilerplate vs Magic
Boilerplate vs Magic
既婚プログラマの時間捻出術
既婚プログラマの時間捻出術
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
ソフトウェアにおける 複雑さとは何なのか?
1.
ソフトウェアにおける 複雑さとは何なのか? kawasima
2.
「複雑さ」を定義する
3.
『A Philosophy of
Software Design』John K. Ousterhout ● 「複雑さ」は理解や修正を難しくするソフトウェアの構造に関連したもの ○ (定義とし書かれているのはこれくらい ) ● 複雑さだと… ○ 単純な変更でもいろんな場所のコードを修正が入る ○ 認知負荷が高い ○ 分からないことが分からない ● 複雑さの原因は… ○ 依存性 ○ 不明瞭さ
4.
『Domain Driven Design』Eric
Evans ● ビジネスルール間に矛盾が発生すると複雑 ● 同じ言葉に違う意味を持たせていると複雑 ● Value Objectで良いものにIDを持たせるのは複雑 一貫性がないと複雑 → ユビキタス言語?
5.
あいまいでよく分からない…
6.
複雑さの言い換え ● 使いにくい ● 理解が難しい ●
メンテしにくい ● 長ったらしい ● 覚えきれない ● 実行が難しい ● 管理できない ● 色々混ざっている ● たくさんの要素がある ● 一貫性がない ● 込み入ってる ● ゴテゴテしている ● 不透明 John Cutlerさんのツイートの裏返し
7.
Simple Made Easy https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md
8.
Rich Hickey定義のComplexity ● 複数の役割 ●
複数のタスク ● 複数の概念 色々混ざっている 一貫性がない
9.
もう1つの複雑さ マイクロサービスの各サービスは Simpleでも…
10.
要素が多くそれらの関係性把握が難しい 込み入っている たくさんの要素がある
11.
2種類の複雑さ ● 単一のコンポーネントに内包される複雑さ ○ 1つのエンティティ、1つのクラス、1つのfunctionに複数の責務・概念が混ざっている。単 一責任原則(SRP)に違反した状態 ○
Simpleの対義語としてのComplexの意 ● コンポーネント数が多いことによる複雑さ ○ エンティティやクラス、functionの数が多く、それぞれの役割や関係性を理解するのが厄 介。 ○ ややこしい意としてのComplicated
12.
2種類の複雑さは可換性がある つまり、巨大なエンティティや巨大なクラスを、 1つ の責務・概念に分解しても、複雑さの総量が変わる わけではない。
13.
『データモデリング入門』渡辺幸三 何をもって 「ひとつの情報のまとまり」とみなすかを明確にしたうえで、それぞれのテーブルにひとつの情報 のまとまりだけを置くように配慮する。このことによって、取り分け手順の複雑さが「テーブルの数の増加」と いう複雑さに移行する。その結果、指示を用意したり改善したりするための手間が減る。
14.
ただし2つの複雑さは対称ではない ❶の注文には、どういう概念が含まれるかパッとは分からない。
15.
ここまでの整理 込み入っている たくさんの要素がある 色々混ざっている 一貫性がない 理解がしにくい メンテがしにくい 長ったらしい 覚えきれない 単一のコンポーネントに 内包される複雑さ コンポーネント数が多いこ とによる複雑さ これら「複雑さ」から 導かれる効果
16.
生来的複雑さを選択する
17.
ここまでは、ソフトウェアが表現するビジネスの持つ 生来的複雑さが、変わらないことを前提としての 話であった。 生来的複雑さは、ビジネス要求によって変わるが、モデルの柔軟性次第でも変わる。
18.
『Analysis Patterns』Martin Fowler ●
システムに柔軟性を持たせすぎると、システムが複雑になりすぎてしまう。 ● エンジニアリングは人工物の構築 , 維持にかかるコストと、それが提供する機能とのトレードオ フを必要とする。
19.
『Clean Code』Uncle Bob ●
道具は道具箱の中に整理され、それぞれが明確に定義されラベル付けされた部品を含む多く の小さな引き出しが必要なのか?それとも、何でも放り込んでおけるような引き出しがいくつか 欲しいのか? ● 複雑さを整理するために、適切なサイズの前者が必要
20.
柔軟性と複雑さ(単純さ)のトレードオフ 例えば、「ピザ」のモデルを考える Cheese Pizza { price:
MonetaryAmount; cheese: Weight; } Pizza { price: MonetaryAmount; dough: Dough; topings: Topping[]; } Product { price: MonetaryAmount; ingredents: Ingredient[]; } 柔軟性 複雑さ (2種類の複雑さの総量 ) (潜在的に)表現可能なモデルの範囲 A) ピザの種類ごとに型を用意する B) ピザで1つの型を用意する C) ピザ以外の商品も表現できるモデル
21.
Case1 単純だが柔軟性にかける 仕様の変更時に、プログラムの修正が発生する。 連れてテーブルの変更も。 → が、このコストは年々小さくなるだろう おそらく、この設計自体が抽象的思考に至りにくいこと が、ビジネス側にも影響を与え、水平思考に繋がらない ことが最大の問題になると思う。 Cheese
Pizza { price: MonetaryAmount; cheese: Weight; }
22.
Case2 柔軟だが決まっていないことが多すぎる Ingredentsの組み合わせには、多くの制約が存在する ことが考えられるが、その制約の設計やテスト容易性を 確保することが困難。 設計時点で、モデルにその自由度が必要なのか? 過剰 な柔軟性であると、Martin
FowlerやUncle Bobの言う 通り、現時点では不必要な複雑さを導入してしまってい ることになる。 Product { price: MonetaryAmount; ingredents: Ingredient[]; }
23.
複雑さのハンドリングガイド ● 複雑さには2種類ある ○ 単一のコンポーネントに内包される複雑さ ○
コンポーネント数が多いことによる複雑 ● 単一のコンポーネントに内包される複雑さは、分解してみないと正体が見えない (すなわち実装どうするかによらず、まず正体を明らかにすることが必要 ) ● 2種類の複雑さの総量は、通常業務の複雑さによって決まるが、モデルにどこまでの柔軟性を 持たせるかによっても変わってくる。 (適度な柔軟性と複雑さを選択しよう )
Download now