Tweet
Tweet

Slide 1

Slide 1 text

使われやすいライブラリの
 ための「コ・ツ」
 社内Unityライブラリの思想と設計
 Gotanda.unity #18 
 ワンダープラネット株式会社 Mikito Yoshiya 


Slide 2

Slide 2 text

吉谷幹人 - Mikito Yoshiya
 
 ワンダープラネット株式会社 
 タノシムスタジオ テックリード 
 @mikito0521
 
 
 
 


Slide 3

Slide 3 text

● これからUnity案件に取り組み始めますか？
 ● 新入社員のオンボーディングに困っていませんか？
 
 専門学校教科書採用実績 
 大手ゲーム会社新卒配布実績 
 【宣伝】改訂版がでます！ 
 Unity2021 実践入門 Amazon (6/15)

Slide 4

Slide 4 text

今日は
 
 
 Unityのライブラリを作る際に
 気をつけたいこと
 
 について話します


Slide 5

Slide 5 text

社内Unityライブラリ・基盤化の取り組み
 ● UI Framework
 ● Networking Framework
 ● Adventure Engine
 ● Time Managemnet
 ● Resource Management
 ● Scene Management
 ● Build / CI Support
 ● Debug Support
 ● Local Storage
 ● ...etc
 
 ＊実ライブラリ名ではありません 
 
 結構がんばっている！


Slide 6

Slide 6 text

SimpleとEasyの話


Slide 7

Slide 7 text

SimpleとEasyは同じようで違う
 ● Simple
 ○ 単純（単一・純粋）
 ○ 混ざっていない、絡んでいない
 
 ● Easy
 ○ すぐに求めることが実現できる、使い始められる 
 ○ 今の自分の能力でできる
 Simple Made Easy (Rich Hickey): https://www.youtube.com/watch?v=kGlVcSMgtV4 
 Simple
 Complex
 Easy
 Hard


Slide 8

Slide 8 text

SimpleとEasyを区別することが大事
 ● Easy - Complex
 ○ 短期的には生産性が高い
 ○ 中期的には生産性が低下することも 
 
 ● Hard - Simple
 ○ 最初は学習が必要
 ○ 中期的には生産性を維持
 


Slide 9

Slide 9 text

SimpleとEasyを区別することが大事
 ● Easy - Complex
 ○ 短期的には生産性が高い
 ○ 中期的には生産性が低下することも 
 
 ● Hard - Simple
 ○ 最初は学習が必要
 ○ 中期的には生産性を維持
 
 場合によってはこちらの方が重要 
 社内ではこっちを優先したいことも多い 


Slide 10

Slide 10 text

Simpleさを保つコツを3テーマに分けて紹介します
 SIMPLE
 COMPLEX
 アンチパターン
 解消パターン


Slide 11

Slide 11 text

混ぜない・絡ませない
 Simpleを保つためのコツ1/3 


Slide 12

Slide 12 text

１ライブラリで多種多様なことが実現できる
 ● いろいろできるはEasyだけど複雑
 
 ● 要素が多くなるほど不要な考慮が増える
 ○ 使わない機能の競合
 ○ リリース・更新回数の増加
 ○ セキュリティリスク
 COMPLEX
 Component A
 Component B
 Component C
 リソース管理
 課金処理
 エディター拡張


Slide 13

Slide 13 text

コンセプトを明確に・責務を1つに
 ● 同タイミングで変更するものはまとめ、異なるものは分ける
 ○ 閉鎖性共通の原則（単一責任の原則） 
 
 ● 適切な名前をつける
 ○ 名は体を表す
 ○ 失敗例：社内のGotandaLib（LINQの拡張ライブラリ） 
 SIMPLE


Slide 14

Slide 14 text

多くの要素・他のライブラリに依存
 ● 依存は複雑
 ○ 依存の解決や競合
 ○ 依存ライブラリのメンテナンス状態の考慮 
 
 ● UPM的な問題もあり
 ○ Unityにおいてライブラリ間の依存解決にまだ難あり 
 ○ OSSはOpenUPMで大分いける？ 
 COMPLEX


Slide 15

Slide 15 text

依存は厳選する
 ● 依存先は安定かどうか
 ● 公式の機能や標準に依存するのはよい
 ○ Unity（uGUI, AssetBundle, JsonUtility, WebRequest...） 
 ○ .NET （LINQ, Task, Cryptography...） 
 ○ 社内標準
 ● 簡易実装で代替できないかを検討
 ○ その代わり拡張を用意：後述
 SIMPLE


Slide 16

Slide 16 text

設定や手順を隠蔽しない
 Simpleを保つためのコツ2/3 


Slide 17

Slide 17 text

全シチュエーションにライブラリ側で自動対応
 ● 利用側からは何も変更ができない
 ○ シリアライズ形式、フォーマット
 ○ ちょっとしたパラメータやステップの付与 
 
 ● ライブラリへの要求と共に複雑性が増す
 ○ 新しいフォーマットへの対応は？ 
 ○ 全てに対してメンテナンスできる？ 
 ○ 細かい設定の調整は？
 COMPLEX
 Pattern A
 Impl
 Pattern B
 Impl
 Pattern C
 Impl
 Library
 Core Logic
 My App


Slide 18

Slide 18 text

抽象化し拡張できるようにしておく
 ● 抽象化したインターフェースを外部に公開
 
 ● ライブラリ利用側で拡張を実装
 ○ 依存注入する
 ○ ライブラリ側で全て作る必要はない！ 
 
 
 SIMPLE
 Pattern A
 Impl
 Library
 Core Logic
 My App
 My Impl
 
 抽象化
 Interface公開
 拡張の実装
 依存の注入


Slide 19

Slide 19 text

抽象化し拡張に対して開く
 ● 依存注入？ for Unity
 ○ ピュアコード x コンストラクタ、セッターインジェクション 
 ○ SerializeField
 ○ SerializeReference
 ○ GetComponentでInterface探す
 ● DIContainer(Extenject/VContainer)
 ○ ライブラリ側で対応を意識できているとよいですね 
 ○ 隠蔽しなければ良い
 
 SIMPLE


Slide 20

Slide 20 text

プレハブを配置すれば自動起動
 COMPLEX
 ● MonoBehaviourはEasyだけど複雑
 ● 初期化タイミングをコントロールしにくい
 ○ 任意のシーケンス中に初期化したい 
 ○ プレイ中に設定変更して再セットアップしたい 
 ● 異なるコンテキストで使いにくい
 ○ 2種の設定を同時に使いたい
 ○ テストで使いたい


Slide 21

Slide 21 text

コアロジックをピュアコード化
 ● 色々なコンテキストで利用できる
 ○ コンストラクタなどに依存や設定を渡す 
 ○ テストも書きやすい
 
 ● グローバルなマネージャーやシングルトンパターンは一考
 ○ ex: MyLibrary.Operation()
 ○ コンストラクタが隠蔽されます
 
 SIMPLE


Slide 22

Slide 22 text

提供しすぎない
 Simpleを保つためのコツ3/3 


Slide 23

Slide 23 text

いろいろなメソッドを公開
 COMPLEX
 ● 不要な要素や選択肢があることは複雑
 
 ● リファクタリングで様々なプロジェクトが死にます
 


Slide 24

Slide 24 text

不要なInterfaceは公開しない
 ● 拡張に対して開き・変更に対しては閉じる
 ○ 全再利用の原則（インターフェース分離の原則） 
 ○ 開発初期は意識的に絞る・拡張性もあとでいい 
 
 ● 最初にテスト/サンプル/Demoをつくる
 ○ 必要最低限がわかる
 SIMPLE


Slide 25

Slide 25 text

超絶UXなエディター拡張
 COMPLEX
 ● GUIはEasyだが複雑
 
 ● エディターコードもソース・機能の一部
 ○ メンテナンスが必要
 ○ 要素が増えれば複雑性は上がる 
 
 


Slide 26

Slide 26 text

GUIが必要か冷静になって考える
 ● そのEasyさ本当に必要ですか？
 
 ● EasyじゃないけどSimpleな方法を探す
 ○ インスペクタの拡張 -> ymlとかjsonとかでデータ読み込み 
 ○ セットアップウィザード -> READMEで手順を説明 
 
 SIMPLE


Slide 27

Slide 27 text

まとめ
 ● ライブラリ開発ではSimple / Easyを区別することが大事
 
 ● Simpleを保つために
 ○ 混ぜない・絡ませない
 ○ 設定や手順を隠蔽しない
 ○ 提供しすぎない


Slide 28

Slide 28 text

注意
 
 ライブラリ・プラグインにはそれぞれコンセプトがあり、
 本資料のアンチパターンが全てに適用されるわけではありません。
 あくまで社内ライブラリの選定基準・開発視点でのお話です。