Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
【オンライン】Clean Architecture 達人に学ぶソフトウェアの構造と設計 輪読会 #1
Search
masyus_work
September 06, 2020
Programming
0
170
【オンライン】Clean Architecture 達人に学ぶソフトウェアの構造と設計 輪読会 #1
masyus_work
September 06, 2020
Tweet
Share
More Decks by masyus_work
See All by masyus_work
ふりかえりとチームクレドが僕らにもたらしてくれたもの
masyus
2
310
【オンライン】Clean Architecture 達人に学ぶソフトウェアの構造と設計 輪読会 #16
masyus
0
140
Clean Architecture 達人に学ぶソフトウェアの 構造と設計_第10回
masyus
0
220
テスト駆動開発 輪読会 Vol.5
masyus
0
160
Chrome拡張で便利ツール作ってたら、思いがけず社内ツールを作ることになった話
masyus
0
150
開発速度UP & エンジニアポートフォリオ作成を同時実現する為の取り組み
masyus
0
180
メール文面確認テストを作りながら、テストについて改めて考えてみた
masyus
0
190
Other Decks in Programming
See All in Programming
Use Perl as Better Shell Script
karupanerura
0
650
SpringBootにおけるオブザーバビリティのなにか
irof
1
890
DevTalks 25 - Create your own AI-infused Java apps with ease
kdubois
2
120
メモリリークが発生した時にpprofを使用して原因特定した話
zono33lhd
0
100
Cloudflare Realtime と Workers でつくるサーバーレス WebRTC
nekoya3
0
230
少数精鋭エンジニアがフルスタック力を磨く理由 -そしてAI時代へ-
rebase_engineering
0
130
TypeScript LSP の今までとこれから
quramy
0
110
iOSアプリ開発もLLMで自動運転する
hiragram
6
2.1k
〜可視化からアクセス制御まで〜 BigQuery×Looker Studioで コスト管理とデータソース認証制御する方法
cuebic9bic
1
270
Rethinking Data Access: The New httpResource in Angular
manfredsteyer
PRO
0
220
CRUD から CQRS へ ~ 分離が可能にする柔軟性
tkawae
0
230
try-catchを使わないエラーハンドリング!? PHPでResult型の考え方を取り入れてみよう
kajitack
3
320
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
Faster Mobile Websites
deanohume
307
31k
Automating Front-end Workflow
addyosmani
1370
200k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.8k
4 Signs Your Business is Dying
shpigford
183
22k
The Cost Of JavaScript in 2023
addyosmani
49
8.1k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
750
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
6
660
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.6k
How to Ace a Technical Interview
jacobian
276
23k
How to train your dragon (web standard)
notwaldorf
92
6k
Transcript
Clean Architecture 達人に学ぶソフトウェアの 構造と設計【輪読会】 第1回:まえがき 〜 第2章 2020/09/09 @masyus_work
アーキテクチャとは何か まえがき
まえがき 1. アーキテクチャの魅力は”構造” - 殊、ソフトウェアは本質的に再帰的でフラクタル 2. ソフトウェアは夢のような世界ではない - 物理的制約を受ける。プロセッサ速度やメモリ、ストレージetc. 3.
優れたアーキテクチャとは - 特定の時点でユーザー・開発者・所有者のニーズを満たす - これから先もニーズを満たし続けることができる - 将来の開発工数やコストを減らせる
まえがき --- 我々の関心事 --- ソフトウェアがソフト(柔軟)であることを認め、 それをシステムで最優先すべき財産として 保持することを目指している - そのために最もクリーンな道のりは何か
まえがき アーキテクチャは、実装と計測によって 証明すべき仮説である。 - 優れたアーキテクチャとは、進行形の探索プロセスである
まえがき 感じたこと - ソフトウェアアーキテクチャ = 可用性の高い設計によって生み出された小 さなコンポーネントの集合体と解釈していた - それ自体は間違っていない -
他方で「実測と計測によって証明すべき仮説である」という解説から、プロ セスそのものであるという解釈が新たに備わった
現代のソフトウェアに 使われている素材は今も昔も変わっていない 序文
序文 1. どんなシステムを作っても、アーキテクチャのルールはどれも同じ - 昔と今で、プログラミングしている中身は変わらないから - 変わったこと - ソフトウェアが動くマシンスペックと物理的サイズ -
アーキテクチャルール - アーキテクチャルールは全ての変数から独立可能
序文 感じたこと - コンピュータの計算能力は半世紀で1022倍強力に - 昔はWebの世界なんて到底実現できなかったのだろう - ハードの進化とソフトの進化は連動している - ムーアの法則が頭に浮かぶ
〜 第I部 イントロダクション 〜 「約束の地はある。 だが、一般的にはクソみたいな設計と 必死に戦うほうが一般的だ」
「急がば回れ」 頭を使って良いアーキテクチャを組めば、 結果的に速さが実現できる 第1章 設計と アーキテクチャ
第1章 設計とアーキテクチャ 1. 設計 = アーキテクチャ 2. 設計 = 下位レベルの詳細
+ 上位レベルの構造 + ... 3. ソフトウェアアーキテクチャの目的 - 求められるシステムを構築・保守するために必要な人材を最小限に抑 えること - 設計の品質 = 労力で計測可能
第1章 設計とアーキテクチャ 1. アーキテクチャが優れていないと将来的に何が起こるか - 開発者人員Up - コード行数が頭打ちになる - KLOC
= Kilo Lines of Code - コードを書けば書くほど影響範囲が拡がり、改修コストUp - 開発生産性Down - 開発者給与Up
第1章 設計とアーキテクチャ 2. 崩壊したコードを書けば長期的には遅くなるものの、短期的には速度が上が る? - 否、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い 3. 我々が注意すべきこと -
後からコードをクリーンにすることはない - 自信過剰であってはならない - 速く進む唯一の方法は、うまく進むこと - 即ち、ソフトウェアアーキテクチャの品質と真剣に向き合うこと
第1章 設計とアーキテクチャ 感じたこと - コードの品質→アーキテクチャの品質に妥協しないこと - レビュー時に相手のスキルセットに迎合しない - プロジェクトの期日を先に押さえられて、そこに何としても間に合わせなけ ればいけない状態を避ける必要がある
- 技術的負債を返却する意義を社内に説明しなくては
ソフトウェア開発チームとして 重視すべきことは何か? 第2章 2つの価値のお話
第2章 2つの価値のお話 1. 全てのソフトウェアシステムは、ステークホルダーに2つの異なる価値を提供 する - 1. 振る舞い - マシンがステークホルダーのためにお金を生み出したり節約した
りできるよう、マシンに振る舞いを与える - 2. 構造 - → アーキテクチャの話
第2章 2つの価値のお話 2. 「ソフト」 + 「ウェア」 と「ハード」 + 「ウェア」 -
「ウェア」 = プロダクト - マシンの振る舞いを容易に変更する => 「ソフト」 - マシンの振る舞いを容易に変更させたくない => 「ハード」 3. 「スコープ」と「形状」の違い - 前回と似たような「スコープ」の変更を伝える - システムの「形状」が要件の「形状」に合わなくなっていく - アーキテクチャの問題 - 形状に囚われないアーキテクチャにする必要がある
第2章 2つの価値のお話 4. ソフトウェアシステムが動くことが大事?それともアーキテクチャ? - 変更が効かず、いずれ役に立たなくなるプログラムを作って良いの か?→ 否 5. アイゼンハワーのマトリクス
- 「緊急」と「重要」の関係性 - 「振る舞い」は緊急だが、常に重要とは限らない - 「アーキテクチャ」は重要だが、常に緊急とは限らない 6. ビジネスマネージャーはアーキテクチャの重要性を評価できない - だからソフトウェア開発者が必要
第2章 2つの価値のお話 大事なこと 「ソフトウェア開発チームには、 機能の緊急性よりも アーキテクチャの重要性を 強く主張する責任が求められる」
第2章 2つの価値のお話 7. どのチームも、常に闘争の渦中にいる - ソフトウェア開発者もステークホルダーであることを忘れてはいけない - アーキテクチャを後回しにしないこと。それがソフトウェアアーキテクト の職務
第2章 2つの価値のお話 感じたこと - スタートアップに求められるビジネス展開の速さは、プロダクトの進化の速 さと連動している - 常に周辺環境が変化していく中で、プロダクトはあらゆる進化を素早く実現 しなければならない -
優れたアーキテクチャがビジネス成功の可否を握ることを肝に命じて、 我々ソフトウェアエンジニアは戦う必要がある
輪読会 第1回は以上になります ありがとうございました!