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
Unityにおける設計パターン
Search
torisoup
February 19, 2021
Technology
17
47k
Unityにおける設計パターン
CA.unity #1
2021/02/19
https://meetup.unity3d.jp/jp/events/1271
torisoup
February 19, 2021
Tweet
Share
More Decks by torisoup
See All by torisoup
もうつまらないとは言わせない!「わかりやすい」プレゼンを作るために気をつけたいこと
torisoup
8
2.3k
Unityの本を出した話
torisoup
3
720
VRMの紹介&VRM勉強会
torisoup
0
97
Unity 1week でつくったゲームにAIを実装してみる
torisoup
2
3.5k
PUN2をasync/awaitで使えるライブラリつくってみた「Pun2Task」
torisoup
0
1.1k
UniTaskの使い方2020 / UniTask2020
torisoup
38
22k
UniTask入門
torisoup
6
20k
ARでVRアバターを表示するシステムを構築しよう
torisoup
2
530
Unity講習資料
torisoup
8
9.1k
Other Decks in Technology
See All in Technology
10分でわかるfreee エンジニア向け会社説明資料
freee
18
520k
Figma Dev Modeで進化するデザインとエンジニアリングの協働 / figma-with-engineering
cyberagentdevelopers
PRO
1
430
30万人が利用するチャットをFirebase Realtime DatabaseからActionCableへ移行する方法
ryosk7
5
330
分布で見る効果検証入門 / ai-distributional-effect
cyberagentdevelopers
PRO
4
700
現地でMeet Upをやる場合の注意点〜反省点を添えて〜
shotashiratori
0
520
オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例
hryushm
14
3k
Nix入門パラダイム編
asa1984
2
200
クライアントサイドでよく使われる Debounce処理 をサーバサイドで3回実装した話
yoshiori
1
150
話題のGraphRAG、その可能性と課題を理解する
hide212131
4
1.5k
新R25、乃木坂46 Mobileなどのファンビジネスを支えるマルチテナンシーなプラットフォームの全体像 / cam-multi-cloud
cyberagentdevelopers
PRO
1
130
MAMを軸とした動画ハンドリングにおけるAI活用前提の整備と次世代ビジョン / abema-ai-mam
cyberagentdevelopers
PRO
1
110
Vueで Webコンポーネントを作って Reactで使う / 20241030-cloudsign-vuefes_after_night
bengo4com
4
2.5k
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
GitHub's CSS Performance
jonrohan
1030
460k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Bash Introduction
62gerente
608
210k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
46
2.1k
Scaling GitHub
holman
458
140k
Transcript
Unityにおける 設計パターン 2021/2/19 とりすーぷ
自己紹介 •とりすーぷ • @toRisouP • VR系の開発してる • Microsoft MVP 2018~
• Developer Technologies • 最近はVRChatしてます illustrations by kota(@kt_kkz)さん
本を出しました •「 UniRx/UniTask完全理解 より高度なUnity C#プログラミング」
今回の話 •設計・アーキテクチャとは •Unityにおける設計のレベル •設計レベルをあげるためには •クリーンアーキテクチャとは •Unityでクリーンアーキテクチャ
発表はショート版です •調子に乗って100枚超のスライド作っちゃった •10分に絶対に収まらないので かなり端折ったショート版で発表します! •公開する資料はフル版です
先に言っておくと •この本読んでください
設計・アーキテクチャとは
設計とアーキテクチャ •設計 • クラス設計、コンポーネントの構成、全体の構成 • 「何をどうやって作っていくか?」という指針
設計とアーキテクチャ •設計 • クラス設計、コンポーネントの構成、全体の構成 • 「何をどうやって作っていくか?」という指針 俯瞰して見た設計をアーキテクチャ と呼ぶ
例:家の建築 •設計 • 壁の位置、形状、配管、配線… •アーキテクチャ • 家全体の形、間取り、部屋のレイアウト…
設計とアーキテクチャ •設計とアーキテクチャは地続きである • 詳細な設計の連続がアーキテクチャを構築する
「設計・アーキテクチャ」の目的 •「システムの開発・保守・運用にかかるコス トを最小限にする」ことが目的
コストを最小限にする •クソコードに振り回される時間を減らす •後の仕様変更にも柔軟(ソフト)に対応する
よくある誤解:その1 「設計を捨てて、開発メンバーが思い思いのや り方で開発した方が効率いいんだけど」
解 •「設計を捨てる」で得られた開発速度は、 後に訪れる莫大な保守コストで帳消しになる • 超短期的には速度が出るが、後に必ず失速する • 長期的に見るなら「ちゃんと設計する」以外に 開発コストを下げる方法はない
ダメなコードの例 •スパゲッティコード • オブジェクトとオブジェクトがどう関係するのかがわからない状態 • 影響範囲が謎でどこを触っていいかわからない状態 • ちょっとした機能変更にもすごく時間がかかる状態 •外部モジュールと一蓮托生した状態 •
「生殺与奪の権を他人に握らせるな」状態 • 外部モジュール(ライブラリやフレームワーク)の機能に強く依存しすぎた結果、 外部モジュールの仕様変更に振り回されてしまうような状態
コードは腐る •少しの油断でコードはすぐにダメになる • 割れ窓理論 • どんな状況においても「設計を守る」を強く意識して 開発に臨む必要がある
よくある誤解:その2 •「巷にある◦◦アーキテクチャっていうのを 使えば万事OKなんでしょ?」
解 •NOです • そもそもアーキテクチャは自分で考えてDIYするもので あり、万能なテンプレートがあるわけではない • プロジェクトに応じて柔軟な設計が求められる
よくある誤解:その3 •「設計とかアーキテクチャって、要件がガチ ガチに固まっている、ブレがないプロジェク トでしかまともに使えないでしょ?」
解 •認識が逆です • 「変化に柔軟に対応できるようにアーキテクチャ を作っていく」が正解 • 機能の変更・追加・破棄があるのはソフトウェアの宿命 • 変化を受け入れられるアーキテクチャを作る、が理想 (現実はメテオフォールなどの根本的なちゃぶ台返しもあり上手くいかないこともあるが、
それは組織体制の問題であって開発者だけで改善できる話ではない)
言い方を変えると •「変更にかかるコストを最低限にする」を達成して いればそれでアーキテクチャとして正解 • 巷にある「◦◦アーキテクチャ」から外れてたり、 アーキテクチャに汚い部分があってもそれで上手く 開発が回っているならそれでOK (設計しなくていい、と言っているわけではない!)
よくある誤解:その4 •「そもそもUnityって特殊なフレームワーク(FW) だと思うんだけど、設計ってやって意味あるの?」
解 •あります。 • FWに振り回されるのは別にUnityに限った話ではない • Unityだけが特別なわけではない • 「(様々な)FWとの上手な付き合い方」はソフトウェア開発の 一般的な問題 •
その対策として「クリーンアーキテクチャ」などの ◦◦アーキテクチャが考案されてきた
設計・アーキテクチャ まとめ •設計・アーキテクチャを使う目的 • 開発・保守・運用にかかるコストを最低限にすること • プロダクトの価値を高め続けられる状態を維持する •アーキテクチャを死守するのが開発者の使命 • 安易に「設計を捨てる」という選択肢を取らない
Unityにおける設計のレベル
レベルわけ •Unityにおける「設計のレベル」を 自分が勝手に決めてみました • 異論・反論は受け付けます(むしろ議論したい)
図の意味 GameObject (with MonoBehaviour) C# Pure C# Package (Assembly Definition
Files)
レベル0:設計が存在しない • 好き勝手作られた状態 • GameObjectベタ置き • 神クラスがたくさん • 相互参照、循環参照、 密結合でぐちゃぐちゃな状態
レベル1:制御フローが整理された状態 • 制御フローが整理された状態 • オブジェクトの役割が明確になった • 参照関係が一方向に • 機能ごとに関係性が整理されている •
密結合なのはそのまま
レベル2:制御フローと依存関係の分離 • 疎結合化が進んだ状態 • SOLID原則が意識されている状態 • 依存関係逆転を考えてインタフェースが 要所要所に利用される C# C#
C#
レベル 3:モジュール化が意識される • 機能ごとにモジュール化される • モジュールの安定性が考慮される • 機能の再利用性が考慮される • asmdefが切られたりする
(コンポーネント、という呼び方もあるが UnityのComponentと被るのでここでは モジュールと呼びます) C# C# C#
レベル 4:ピュアなC#を活用する • ピュアなC#がメインロジック化 • MonoBehaviourを使わない実装が増える C# C# C# C#
C# ←Unity依存はここだけ
レベル 5:アーキテクチャが意識される • 全体のアーキテクチャを考慮 して一貫した作りになる • 詳細設計のみではなく、 全体を俯瞰してみた設計 (アーキテクチャ)が 強く意識される状態
• レイヤの概念が入ってくるなど C# C# C# C# ↓Unity依存はここだけ C# C# C# C#
レベル分け 5:アーキテクチャが意識される 4:ピュアなC#が活用される 3:モジュール化が意識される 2:制御フローと依存関係が分離する 1:フローが整理される 0 : 設計なし
レベル分け 5:アーキテクチャが意識される 4:ピュアなC#が活用される 3:モジュール化が意識される 2:制御フローと依存関係が分離する 1:フローが整理される 0 : 設計なし ハイリスク
ローリターン どんな状況でも最低限達成したい できてればよりGood コストは高いが メリットも大きい
設計レベルをあげるメリット •長期開発における機能追加・保守・運用の コストが下がる • 機能追加や仕様変更に柔軟に対応できるようになる • 大人数で開発しても破綻しにくい体制が作れる
設計レベルをあげるデメリット •開発者に対する負担も上がる • 開発規模に見合わない設計レベルは逆に手間を増やす • 開発者に求められる設計スキルも高くなる •動作パフォーマンスが落ちる場合もある • 「DIが遅い」「GCアロケートが増える」 •
チューニングのためベタ書きコードがどうしても必要になる
トレードオフ ⇔ • 理想を語るなら「長期的な運用のしやすさ」に振りたいが… • 現実は様々な理由で妥協しなくてはいけないことが多い • 場面によってはレベル1~4の範囲で収まってても全然よい 短期的な開発のしやすさ 極限を求めるチューニング
長期的な運用のしやすさ
大事なこと •チームがやりやすいレベルで止めてもよい • 難しいと感じたらレベルを下げるのもあり • ただし最低でも「レベル1」は維持したい •設計レベルをハイブリッドにしても良い • チューニングしたいところはUnityと密にする •
Unityと関係ない部分はできるだけピュアC#で書く
ハイブリッドなやり方 C# C# C# C# C# C# C# C# C#
C# レベル2で 構成された領域 レベル5で 構成された領域 依存
設計レベル まとめ •Unityにおける設計をレベルわけしてみた • 勝手に決めたレベルなので異論反論は受け付ける •どのレベルで開発するかバランスをみるの大事 • 理想としてはレベル5を目指していきたいが、 現実はそこまでいけることは稀 •
どこかでバランスを取る必要がある
設計レベルをあげるためには
設計レベルの壁を超えるためには? 5:アーキテクチャが意識される 4:ピュアなC#が活用される 3:モジュール化が意識される 2:制御フローと依存関係が分離する 1:フローが整理される 0 : 設計なし ここの壁を超えるためには?
レベル0→レベル1 •制御フローの整理を意識しよう • 制御フローをキレイにすることが何よりも大事 • フローさえ整っていれば最低限スパゲッティコードは 回避ができる
制御フロー •「誰が」「誰に」命令をするのかの流れ • オブジェクトの責務、メッセージの流れ ぐちゃぐちゃなフローの例 整理されたフローの例
制御フローの整理 1. オブジェクトのもつ役割をハッキリさせる 2. オブジェクトごとの主従関係をハッキリさせる 3. 相互参照、循環参照を避けて データの流れをわかりやすくする これで レベル0
→ レベル1 に上がる
レベル2以上を目指すなら •制御フローに実装が振り回されない対策 が必要になる • オブジェクトの制御フローをそのままコードに落とし込んでい るだけではダメ(密結合化してしまい柔軟性がなくなる)
学ぶべきもの •「設計原則」を学ぶべし • 設計原則は「制御フローを変えずにどうキレイに実装す るか?」というやり方をまとめたもの
設計原則 •SOLID原則 • SRP、OCP、LSP、ISP、DIP •コンポーネントの凝縮性の原則 • REP、CCP、CRP •コンポーネントの結合性の原則 • ADP、SDP、SAP
設計原則 •SOLID原則 • SRP、OCP、LSP、ISP、DIP •コンポーネントの凝縮性の原則 • REP、CCP、CRP •コンポーネントの結合性の原則 • ADP、SDP、SAP
←制御フローと実装の分離に必須(レベル2に必須)
設計原則 •SOLID原則 • SRP、OCP、LSP、ISP、DIP •コンポーネントの凝縮性の原則 • REP、CCP、CRP •コンポーネントの結合性の原則 • ADP、SDP、SAP
←より大局的な視点での設計の話 (レベル3以上に必須) ←より大局的な視点での設計の話 (レベル3以上に必須)
詳しくは •この本読んでください
必要なこと 5:アーキテクチャが意識される 4:ピュアなC#が活用される 3:モジュール化が意識される 2:制御フローと依存関係が分離する 1:フローが整理される 0 : 設計なし 制御フローを意識しよう
SOLID原則を学ぼう コンポーネントの 凝縮性・結合性の原則 を学ぼう
一番大事なテクニック •「依存関係の逆転」 • 依存関係逆転の原則(DIP)を行うのに必須 • これができるだけでもかなり違うので絶対覚えたい
依存関係の逆転 •制御フローはそのままに、 モジュールの依存関係を逆転させるテクニック • インタフェースを活用するワザ • これができると疎結合化が進む
uGUI.Text UnityEngine.UI 例:MVPパターン •Model – View – Presenterパターン • PresenterがModelとViewの連結を行うデザインパターン
• (Unityの場合は View = UnityEngine.UI) Presenter Model
uGUI.Text UnityEngine.UI 制御フローと依存関係が一致 • PresenterがModelとViewの2つを参照する Presenter Model 依存する 依存する
コード例
コード例 PresenterがViewとModel を参照している
uGUI.Text UnityEngine.UI 依存関係 Model Presenterパッケージ Presenter.cs 依存する 依存する
依存関係を逆転させたい •PresenterがViewを操作するのは変わらないが、 依存関係は逆にしたい Presenter Model 制御フロー 制御フロー 依存する 依存する uGUI.Text
UnityEngine.UI
やり方 1. Presentersパッケージ内にインタフェース を定義する
依存関係 Model Presenterパッケージ Presenter.cs 依存する ITextPrinter.cs uGUI.Text UnityEngine.UI
やり方 2. Viewsパッケージを定義して、 そこでITextPrinterを実装する
依存関係 Model Presenterパッケージ Presenter.cs 依存する ITextPrinter.cs TextView.cs 依存する Viewsパッケージ uGUI.Text
UnityEngine.UI
やり方 3. PresenterがITextPrinterを使う
依存関係の逆転完了 Model Presenterパッケージ Presenter.cs 依存する ITextPrinter.cs TextView.cs Viewsパッケージ uGUI.Text UnityEngine.UI
依存する
依存関係の逆転完了 Model Presenterパッケージ Presenter.cs 依存する ITextPrinter.cs TextView.cs Viewsパッケージ uGUI.Text UnityEngine.UI
PresenterとViewの依存が逆になった! 依存する
制御フローは変わってない! Model Presenterパッケージ Presenter.cs 依存する ITextPrinter.cs TextView.cs Viewsパッケージ uGUI.Text UnityEngine.UI
更新 R/W 依存する
依存関係の逆転 •どんなものでも依存関係は逆転できる • 制御フローはそのまま維持できる! •これを上手く活用してねっていうのが 「依存関係逆転の原則(DIP)」
設計レベルをあげるためには まとめ •制御フローを意識しよう • オブジェクト間の関係をハッキリさせる •制御フローに振り回されない対策をしよう • 設計原則をしっかり抑える • 依存関係の逆転がかなり大事
(補足) • UnityのMVPパターンでここまでやるのは「冗長」 • 最初のPresenter→Viewの参照の形で困ってないなら、無理に この形に変形する必要はないです(あくまでサンプルとして挙げただけ) Model Presenterパッケージ Presenter.cs 依存する
ITextPrinter.cs TextView.cs 依存する Viewsパッケージ uGUI.Text UnityEngine.UI
クリーンアーキテクチャ(CA)
すっごい雑にいうと 「君だけの最強の アーキテクチャをつくろう!」 (そのための指標に“クリーンアーキテクチャ” を使うべし!)
アーキテクチャの考え •そのソフトウェアに最適なアーキテクチャは、 自分たちで模索して育てるしかない • 万能な「アーキテクチャ」は存在しない! • 自分たちのニーズに応じて自分たちでアーキテクチャを 考えて作るしかない
クリーンアーキテクチャとは 様々なアーキテクチャに 共通するルールをまとめたもの こういうルールでアーキテクチャを作ると上手くいくことが多いよね、 という指標を提示するもの
ざっくり言うと 過去に提唱されてきた「オニオンアーキテクチャ」「ヘキサゴナルアー キテクチャ」とかって何かどれも同じこと言ってね? ↓ つまり基本的な考えは同じでやり方が異なるだけでは? ↓ 共通部分を抜き出してみよう ↓ クリーンアーキテクチャ
クリーンアーキテクチャのルール 「依存関係は上位レベルに向け一方通行にしろ」 「制御フローと依存関係を分離しろ」
クリーンアーキテクチャでは •具体的に「こうしろ!」とは言ってない • レイヤ数やコンポーネント名は自由に決めていい • レイヤ/コンポーネント構成を後から変更しても良い • 小さいアーキテクチャから始めてだんだん大きくしても良い
この図は何なの?
「レイヤを4つ用意するんだな…?」 「実装をこの図に上手く配置しろってことだな?」 よくある誤解
「レイヤを4つ用意するんだな…?」 「実装をこの図に上手く配置しろってことだな?」 よくある誤解
この図でいいたいところ • 依存性は常に上位レベル(内側) にのみ向かってなくてはいけない! この小さい矢印が一番重要
• この図はただの「たとえ」 • 「Webを例にするならこういう作り方もあるよね」くらいのノリ • レイヤ数やコンポーネントは自由に定義してよい この図に振り回されてはいけない
ここの部分 •「依存関係の逆転」 を使って依存関係と制御フロー を分離しろ
クリーンアーキテクチャ まとめ •クリーンアーキテクチャは「指標」 • DIYするときの指針をまとめたもの、くらいの認識 • 具体的なレイヤ定義やコンポーネント定義は一切してない •設計原則を学ぶのが一番大事 • 設計原則を抑えておかないとうまくアーキテクチャは作れない
• CA本でも第22章までCAの話が出てこない(それだけ前提知識が必要)
Unityでクリーンアーキテクチャ
Q. UnityでCAってできるの? •A.「アーキテクチャの基本的な考え方」 に則ればUnityと共存できます
とある考え方 •「Unity」という土台の上にクリーンアーキテ クチャで世界を作ろうとしている Unity クリーンアーキテクチャ
とある考え方 •「Unity」という土台の上にクリーンアーキテ クチャで世界を作ろうとしている → この考え方だと失敗する Unity クリーンアーキテクチャ
アーキテクチャの考え方 •「フレームワークと結婚するな!」 • アーキテクチャの上位レイヤにフレームワークを持ってくるな! • フレームワークの都合でアーキテクチャが振り回されるべきではない!
何と結婚するのかよく考えること •ライブラリ系もよく考えよう • UniRxとかそういうやつ • 上位レイヤで使ったほうが話が早いなら結婚してOK • ただし後から切り離しはできなくなるので覚悟が必要
Unityでクリーンアーキテクチャ •Unity側がアーキテクチャ側に依存するべき • Unityとは独立してCAでコンポーネントを構成し、 それをUnity側が利用する形にするべき CAな世界 Unity 依存
実際どうするのか? 「レベル間の違う領域のハイブリッド」 をやればOK
2つの世界の両立 C# C# C# C# C# C# C# C# C#
C# UnityEngineに べったりな世界 (レベル2) CAで構築された世界 (レベル5) 依存
使い分け •Unity非依存でロジックが構築できる部分 → クリーンアーキテクチャが適用可能 •UnityEngineを使わざるを得ない部分 → MonoBehaviourベタ書きを多用で対処する
両極端に振れず、 ハイブリッドにするという択があることを 忘れてはいけない
UnityでCA まとめ •UnityでCAは利用可能 • Unityが関係無い部分はCAで作ることができる • ただしUnityEngineの機能に強く依存する部分は相性悪い •UnityとCAの関係性には注意 • UnityのアーキテクチャにCA側が振り回されてはいけない
(補足)CAFU •CAFU: Clean Architecture for Unity • そっくりそのまま利用はオススメしません(断言) • 黎明期に提案されたCAのテンプレート
• コンポーネント定義がちょっとやりすぎで煩雑 • 作者本人も「やりすぎた」と反省している • テンプレートそのまま使うのではなく、 開発規模にあったサイズのアーキテクチャを自分で考えるべき
最後のまとめ
最後に •最初から完璧なアーキテクチャは存在しない • 「アーキテクチャ」もまた開発過程で成長していく • 「プロダクトの開発・保守・運用ににかかるコストを最 低限にする」が目的であり、そこが達成できるなら 多少キタナイ部分があってもOK
クリーンアーキテクチャになってなくても、 設計原則に違反する部分があっても、 Unityと密結合してる部分があっても、 それがやりやすいならそれで良い (設計しなくていいと言ってるわけではない!「バランス感を持て!」という話)
参考資料 • 世界一わかりやすいClean Architecture • https://www.nuits.jp/entry/easiest-clean-architecture-2019-09 • Adaptive Code ~
C#実践開発手法 第2版 • https://www.amazon.co.jp/dp/B07DJ2BL4Y/ • Clean Architecture 達人に学ぶソフトウェアの構造と設計 • https://asciidwango.jp/post/176293765750/clean-architecture