【オンライン】Clean Architecture 達人に学ぶソフトウェアの構造と設計 輪読会 #1

Transcript

1. Clean Architecture 達人に学ぶソフトウェアの 構造と設計【輪読会】 第1回：まえがき 〜 第2章 2020/09/09 @masyus_work
2. アーキテクチャとは何か まえがき
3. まえがき 1. アーキテクチャの魅力は”構造” - 殊、ソフトウェアは本質的に再帰的でフラクタル 2. ソフトウェアは夢のような世界ではない - 物理的制約を受ける。プロセッサ速度やメモリ、ストレージetc. 3. 優れたアーキテクチャとは - 特定の時点でユーザー・開発者・所有者のニーズを満たす - これから先もニーズを満たし続けることができる - 将来の開発工数やコストを減らせる
4. まえがき --- 我々の関心事 --- ソフトウェアがソフト（柔軟）であることを認め、 それをシステムで最優先すべき財産として 保持することを目指している - そのために最もクリーンな道のりは何か
5. まえがき アーキテクチャは、実装と計測によって 証明すべき仮説である。 - 優れたアーキテクチャとは、進行形の探索プロセスである
6. まえがき 感じたこと - ソフトウェアアーキテクチャ = 可用性の高い設計によって生み出された小 さなコンポーネントの集合体と解釈していた - それ自体は間違っていない - 他方で「実測と計測によって証明すべき仮説である」という解説から、プロ セスそのものであるという解釈が新たに備わった
7. 現代のソフトウェアに 使われている素材は今も昔も変わっていない 序文
8. 序文 1. どんなシステムを作っても、アーキテクチャのルールはどれも同じ - 昔と今で、プログラミングしている中身は変わらないから - 変わったこと - ソフトウェアが動くマシンスペックと物理的サイズ - アーキテクチャルール - アーキテクチャルールは全ての変数から独立可能
9. 序文 感じたこと - コンピュータの計算能力は半世紀で1022倍強力に - 昔はWebの世界なんて到底実現できなかったのだろう - ハードの進化とソフトの進化は連動している - ムーアの法則が頭に浮かぶ
10. 〜 第I部 イントロダクション 〜 「約束の地はある。 だが、一般的にはクソみたいな設計と 必死に戦うほうが一般的だ」
11. 「急がば回れ」 頭を使って良いアーキテクチャを組めば、 結果的に速さが実現できる 第1章 設計と アーキテクチャ
12. 第1章 設計とアーキテクチャ 1. 設計 = アーキテクチャ 2. 設計 = 下位レベルの詳細 + 上位レベルの構造 + ... 3. ソフトウェアアーキテクチャの目的 - 求められるシステムを構築・保守するために必要な人材を最小限に抑 えること - 設計の品質 = 労力で計測可能
13. 第1章 設計とアーキテクチャ 1. アーキテクチャが優れていないと将来的に何が起こるか - 開発者人員Up - コード行数が頭打ちになる - KLOC = Kilo Lines of Code - コードを書けば書くほど影響範囲が拡がり、改修コストUp - 開発生産性Down - 開発者給与Up
14. 第1章 設計とアーキテクチャ 2. 崩壊したコードを書けば長期的には遅くなるものの、短期的には速度が上が る？ - 否、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い 3. 我々が注意すべきこと - 後からコードをクリーンにすることはない - 自信過剰であってはならない - 速く進む唯一の方法は、うまく進むこと - 即ち、ソフトウェアアーキテクチャの品質と真剣に向き合うこと
15. 第1章 設計とアーキテクチャ 感じたこと - コードの品質→アーキテクチャの品質に妥協しないこと - レビュー時に相手のスキルセットに迎合しない - プロジェクトの期日を先に押さえられて、そこに何としても間に合わせなけ ればいけない状態を避ける必要がある - 技術的負債を返却する意義を社内に説明しなくては
16. ソフトウェア開発チームとして 重視すべきことは何か？ 第2章 2つの価値のお話
17. 第2章 2つの価値のお話 1. 全てのソフトウェアシステムは、ステークホルダーに2つの異なる価値を提供 する - 1. 振る舞い - マシンがステークホルダーのためにお金を生み出したり節約した りできるよう、マシンに振る舞いを与える - 2. 構造 - → アーキテクチャの話
18. 第2章 2つの価値のお話 2. 「ソフト」 + 「ウェア」 と「ハード」 + 「ウェア」 - 「ウェア」 = プロダクト - マシンの振る舞いを容易に変更する => 「ソフト」 - マシンの振る舞いを容易に変更させたくない => 「ハード」 3. 「スコープ」と「形状」の違い - 前回と似たような「スコープ」の変更を伝える - システムの「形状」が要件の「形状」に合わなくなっていく - アーキテクチャの問題 - 形状に囚われないアーキテクチャにする必要がある
19. 第2章 2つの価値のお話 4. ソフトウェアシステムが動くことが大事？それともアーキテクチャ？ - 変更が効かず、いずれ役に立たなくなるプログラムを作って良いの か？→ 否 5. アイゼンハワーのマトリクス - 「緊急」と「重要」の関係性 - 「振る舞い」は緊急だが、常に重要とは限らない - 「アーキテクチャ」は重要だが、常に緊急とは限らない 6. ビジネスマネージャーはアーキテクチャの重要性を評価できない - だからソフトウェア開発者が必要
20. 第2章 2つの価値のお話 大事なこと 「ソフトウェア開発チームには、 機能の緊急性よりも アーキテクチャの重要性を 強く主張する責任が求められる」
21. 第2章 2つの価値のお話 7. どのチームも、常に闘争の渦中にいる - ソフトウェア開発者もステークホルダーであることを忘れてはいけない - アーキテクチャを後回しにしないこと。それがソフトウェアアーキテクト の職務
22. 第2章 2つの価値のお話 感じたこと - スタートアップに求められるビジネス展開の速さは、プロダクトの進化の速 さと連動している - 常に周辺環境が変化していく中で、プロダクトはあらゆる進化を素早く実現 しなければならない - 優れたアーキテクチャがビジネス成功の可否を握ることを肝に命じて、 我々ソフトウェアエンジニアは戦う必要がある
23. 輪読会 第1回は以上になります ありがとうございました！