【地域おこし勉強会 第3回】ソフトなソフトウェアを作る【2023_10_25】

Transcript

1. ソフトなソフトウェアを作る 波紫寛斗（はし）
2. 本勉強会のゴール • ソフトウェアにおける２つの価値を学ぶ • ソフトなソフトウェアを作るためのソフトウェアアーキテクチャの原則を学ぶ
3. ベースにする本 『Clean Architecture - 達人に学ぶソフトウェアの 構造と設計』 著： Robert C. Martin
4. 目次 1. 設計とアーキテクチャ 2. ソフトウェアにおける２つの価値 3. 構造を実現するソフトウェアアーキテクチャ
5. システム設計とアーキテクチャ
6. システム設計とアーキテクチャ • システム設計＝アーキテクチャ • アーキテクチャの目的 ◦ システムを適切に動作させること ◦ システムのライフサイクル（理解→開発→デプロイ→保守・運用）のコストを最小 限に抑える ◦ システムを安定して継続させる • しかし、この目的は大抵満たされない ◦ →なぜか？
7. なぜ我々はアーキテクチャの目的を満たせないのか • 「あとで設計を綺麗にすればいい」という思考 ◦ 市場（顧客、ユーザー）からの要望は絶え間ない ◦ そのため、新機能の開発に追われてきれいにすることができない • アーキテクチャが綺麗でなくても売上は上がる ◦ 「ちゃんと動く」ことを満たせていれば顧客はひとまず OKを出す • 人と時間をかければ綺麗なプログラムでなくても改修可能（ある程度） ◦ しかし、生産性はどんどん落ちていく 負のスパイラルへ
8. アーキテクチャを正さないことによる負のスパイラル 売上が上がる 新たな要望 生産性の低下 時間と人を かけて開発
9. アーキテクチャを正さないことによる負のスパイラル • 売上を求めすぎて、アーキテクチャを正さないと負のスパイラルへ • アーキテクチャを正すのを優先しすぎると売上が上がらない • どちらを優先すべきなのか？ ◦ →ソフトウェアにおける２つの価値を理解した上で決定する
10. ソフトウェアにおける２つの価値
11. ソフトウェアにおける２つの価値 • すべてのシステムは、ステークホルダーに「振る舞い」と「構造」を提供 • プログラマはマシンに「振る舞い」を与え、マシンが要件を満たしてなければそれを 修正する • プログラマはマシンにどのように振る舞いを実装するか、といった「構造」を考えるこ とも行う どちらが重要な価値か？
12. ２つの価値のどちらが重要か • 「システムは動作することが重要である」→（筆者曰く）これは間違い！ • なぜか？→以下の2つの例をもとに考える ◦ 完璧に動作、変更できないプログラム。要件が変更されると機能しなくなるため、い ずれ役に立たなくなる ◦ 動作しないが、変更が簡単なプログラム。要件が変更されても修正は可能なので、 引き続き役に立つ • 実際は変更できないプログラムはないが、変更コストがメリットを上回っており事 実上できないものは存在する 重要なのは「構造」である
13. 「振る舞い」は 重要ではないのか？
14. 重要ではない しかし、 緊急ではある
15. 緊急と重要は違う • 「振る舞い」は緊急だが、常に重要とは限らない→優先度1 or 3 • 「構造」は重要だが、常に緊急とは限らない→優先度 2 or 4
16. 構造を実現する ソフトウェアアーキテクチャ
17. ソフトウェアアーキテクチャとは？ • 2つの価値のうち「構造」を実現するもの ◦ 決して神秘的なものではない • アーキテクチャの目的（２回目） ◦ システムを適切に動作させること ◦ システムのライフサイクル（理解→開発→デプロイ→保守・運用）のコストを最小 限に抑える ◦ システムを安定して継続させる • どのようにすれば、この目的が実現できるのか？ ◦ →選択肢を残しておく。 ◦ 詳細非依存 ◦ 独立化
18. 詳細非依存 • 詳細を早期に決定してしまい、詳細と密結合している状態であると何が起こるの か？ ◦ 依存先の詳細（デバイス・DB・UI等）の変更があったときに改修コストが大きく なってしまう ◦ システムが安定しない、システムのライフサイクルのコストが高くなる • そのため、はじめから１つの詳細の選択肢のみにこだわったアーキテクチャならば ソフトにはならない（＝簡単には変更できない） • しかし、チームの規模が小さく強固な構造を望んでいないプロジェクトではアーキテ クチャの構造が逆に障害となる ◦ →緊急・重要の話と強く関連
19. 各ライフサイクルの要素の独立化 • 独立な開発 ◦ コンポーネントを明確に切り離す ◦ もしユースケースが切り離されていれば、異なるユースケース間のビジネスロ ジックの実装で互いが邪魔になる可能性が低い • 独立なデプロイ ◦ もしユースケースやコンポーネントが切り離されていれば、稼働するシステム で変更したい要素をホットスワップ（＝稼働させたまま置き換える）することも可 能 ◦ 新しいユースケースを追加するときは、その他の部分はそのままで新しいjar ファイル等を追加するだけになる • 独立な保守・運用 ◦ それぞれ異なるサーバーに配置して繋げる（e.g. マイクロサービス等）
20. どのレベルで独立化するのが良いのか • 単に「独立化」といっても、以下のように複数の独立化のレベルがある ◦ 開発レベル：あるモジュールの変更が他のモジュールの変更や再コンパイル に繋がらないようにする ◦ デプロイレベル：あるモジュールのデプロイが、他のモジュールの再ビルド・デ プロイに繋がらないように、デプロイ可能な単位（＝コンポーネント）の依存性 を管理する ◦ 実行単位（サービス）レベル：依存性をデータ構造のレベルまで下げ、ネット ワークパケットだけで通信をする ◦ etc… • これに対し明確な正解はない • 時間とともに変化する可能性がある
21. 勉強会のまとめ • 緊急と重要は違う • 重要な価値を実現するもの→ソフトウェアアーキテクチャ • ソフトウェアアーキテクチャの目的 ◦ システムを適切に動作させる ◦ システムのライフサイクルのコストを最小限に抑える ◦ システムを安定的に継続させる • ソフトウェアアーキテクチャの目的実現のために必要なこと ◦ 詳細非依存 ◦ 独立化
22. 優れたアーキテクチャは 選択肢を常に多く残しておくも のである 「Clean Architecture - 達人に学ぶソフトウェアの構造と設計」 Robert C. Martin
23. ソフトなソフトウェアを作る 波紫寛斗（はし）