そろそろ軽率に クリーンアーキテクチャ（な思考） の話がしたくて / i want to talk about a think of clean architecture thoughtlessly

Transcript

1. そろそろ軽率に クリーンアーキテクチャ（な思考） の話がしたくて IwakenLab設計座談会 にー兄さん(@ninisan_drumath)
2. 発表資料は公開します👍 スクショ等のSNS共有OKです📸
3. にー兄さん(@ninisan_drumath) 自称Unity・ARエンジニア ロケーションベースAR / Unity / WebAR / Babylon.js / Azure Kinect 最新技術を使ったデモンストレーションが好き - 筑波大学 情報科学類 - 株式会社ホロラボ アルバイト - Microsoft 学生アンバサダー - Iwaken Lab
4. アジェンダ - はじめに - ”ソフト”ウェアについて考える - 安定性の議論 - Unityと結婚するな！ - おわりに
5. はじめに
6. 本発表のゴール 変更に柔軟なソフトウェア開発の考え方を理解する Clean Architecture本を読む足掛かりを作る
7. 本発表のターゲット - （Unity開発者） - 参加者にUnity経験者が多いため便宜上 - 設計原則への理解がある / 理解にチャレンジしている - 大規模ソフトウェア開発に興味がある - （クリーン）アーキテクチャという言葉は知ってる
8. 所感 CAの概念を理解するのはeasyではない 普遍的なソフトウェア開発の知識であるため抽象度高め OOPやSOLID原則の理解の上にある あえて「あの図」は出さないことに（雑談フェーズで出すかも） 「あの図」から生まれる誤解を10分で解くのは難しいため 加えて実現するのも結構難しい（という理解をしている） CAは理想形にすぎないが、理想形を知ることはとても重要である 根拠のある妥協をしよう
9. 諸注意・免責 私自身は大規模開発の経験は少ないため、「頭でっかち」な部分があります 実際の現場では適切にアーキテクチャを選択する必要がありますが 本発表ではあくまで「理想論」という受け止め方をしてください マサカリは研がない・投げない・振り回さない 本発表内容によって被った損害・損失については一切の責任を負いかねます。 ご了承ください。
10. ”ソフト”ウェアについて考える
11. 何がソフトウェアを「ソフト」たらしめるのか
12. 何がソフトウェアを「ソフト」たらしめるのか 変更の柔軟性 ハードウェアは容易に変更できない ソフトウェアは容易に変更できる
13. なんで変更するのか、そもそも変更とは何か 理由・モチベ - 新機能の追加の要望 - バグの修正 - ライブラリのアップデート - リファクタリング - パフォーマンス向上 内容 - ページ（UI）の追加 - 採用ライブラリの変更 - 新規デバイスの対応実装 - データベース設計の変更 変更の理由や内容は様々
14. 長く続くソフトウェアの運用 ソフトウェアは生き物である（生まれ、成長し、死ぬ） 寿命を長くするためには長期的なメンテナンスが不可欠 しかしソフトウェアは機能を追加すればするほど メンテナンスコストが上がっていく 機能間で無駄な依存関係がある →一つの変更理由でいくつも機能変更が生じる →避けたい事態 設計によって、変更に強い”ソフト”ウェアを作ろう！
15. 安定性の議論
16. プログラムの基本は入力と出力 プログラムの基本形は 入力を受け取り出力を返す 大きなプログラムになっても 入出力の集合になっている 例えばユーザの入力を受け取 り、画面に出力したりデータベー スに出力したり
17. 内部的には複数のプログラムを経由することになる
18. ＜疑問＞ プログラムの全部がまんべんなく 「ソフト」であるべきなのか？
19. A. 柔軟な部分とそうでない部分があってよい プログラムのすべてが変更される可能性は極めて低い （それはもはや別サービス） つまりビジネスロジックは変更されにくい 逆に変更されやすい部分 - ボタンの色や形 - ページやメニューの種類 - 対応デバイス - 外部API - DBMSの種類
20. 安定部分と柔軟部分は分けて考える ビジネスロジック 見た目やデータストア 安定 柔軟 上位モジュール 下位モジュール 方針 詳細
21. 一応依存方向について復習
22. 処理の流れと依存方向は？ new A(); class A { public A() { new B(); } } class B { public B() { new C(); } } class C { }
23. 処理の流れ 依存方向 A C B AがBを呼ぶ BがCを呼ぶ A C B AがBに依存 BがCに依存
24. 処理の流れと依存方向について ＜愚直な実装＞ 一番最後の出力ロジックに ドメインロジックが依存する 下位モジュールは不安定だから依 存したくない DIPにのっとり、依存方向を逆転さ せる
25. 依存方向 A C B AがBに依存 BがCに依存 依存方向 A C B AがBに依存 CがICを実装 B名前空間に依存 IC DIP BがICに依存
26. 実線：依存方向　点線：処理の流れ
27. 詳細が方針に 依存するようにせよ （逆はダメ）
28. モジュールの境界で 依存方向を適切に制御 せよ
29. Unityと結婚するな （最後に小噺的な）
30. 詳細について知ろう ここでいうUnityとは詳細のこと RailsもASP.NETもReact/Vueも MySQLもFirebaseもSupabaseも HoloLensもQuest Proも
31. 詳細と結婚しないメリット 1. 詳細を差し替えられる 2. 詳細の意思決定を遅延できる
32. しかし、あなたは詳細は求婚されている フレームワークは依存を迫ってくる 「私の抽象クラスを継承して♡」 渋い顔をしながら断るか、適切な根拠を持って結婚するか
33. おわりに
34. まとめ クリーンアーキテクチャの考え方 - 詳細が方針に依存するように - そのためにモジュール境界で適切に依存関係を制御せよ これをどこまでしっかりやるか 見極められるようになりたい
35. 参考文献 Clean Architecture 達人に学ぶソフトウェアの構造と設計 https://www.amazon.co.jp/Clean-Architecture-%E9%81%94%E4%BA%BA%E3%81%AB%E5%AD%A6%E3%81%B6%E3%82%BD% E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%81%AE%E6%A7%8B%E9%80%A0%E3%81%A8%E8%A8 %AD%E8%A8%88-Robert-C-Martin/dp/4048930656 世界一わかりやすい Clean Architecture https://www.nuits.jp/entry/easiest-clean-architecture-2019-09 クリーンアーキテクチャ完全に理解した https://gist.github.com/mpppk/609d592f25cab9312654b39f1b357c60 実装クリーンアーキテクチャ https://qiita.com/nrslib/items/a5f902c4defc83bd46b8 clean architecture と asmdef - 【年末だよ】Unity お・と・なのLT大会 2019 https://www.youtube.com/watch?v=PdYeUu2-gOU Clean Architecture for Unity https://learning.unity3d.jp/4021/