Upgrade to Pro — share decks privately, control downloads, hide ads and more …

使われやすいライブラリのための「コ・ツ」〜社内Unityライブラリの思想と設計〜/simple-unity-library

 使われやすいライブラリのための「コ・ツ」〜社内Unityライブラリの思想と設計〜/simple-unity-library

Eb6733f8d1fe3c983ff11b830945eccb?s=128

Mikito Yoshiya

May 26, 2021
Tweet

Transcript

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


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


    @mikito0521
 
 
 
 

  3. • これからUnity案件に取り組み始めますか?
 • 新入社員のオンボーディングに困っていませんか?
 
 専門学校教科書採用実績 
 大手ゲーム会社新卒配布実績 
 【宣伝】改訂版がでます!

    
 Unity2021 実践入門 Amazon (6/15)
  4. 今日は
 
 
 Unityのライブラリを作る際に
 気をつけたいこと
 
 について話します


  5. 社内Unityライブラリ・基盤化の取り組み
 • UI Framework
 • Networking Framework
 • Adventure Engine


    • Time Managemnet
 • Resource Management
 • Scene Management
 • Build / CI Support
 • Debug Support
 • Local Storage
 • ...etc
 
 *実ライブラリ名ではありません 
 
 結構がんばっている!

  6. SimpleとEasyの話


  7. SimpleとEasyは同じようで違う
 • Simple
 ◦ 単純(単一・純粋)
 ◦ 混ざっていない、絡んでいない
 
 • Easy


    ◦ すぐに求めることが実現できる、使い始められる 
 ◦ 今の自分の能力でできる
 Simple Made Easy (Rich Hickey): https://www.youtube.com/watch?v=kGlVcSMgtV4 
 Simple
 Complex
 Easy
 Hard

  8. SimpleとEasyを区別することが大事
 • Easy - Complex
 ◦ 短期的には生産性が高い
 ◦ 中期的には生産性が低下することも 


    
 • Hard - Simple
 ◦ 最初は学習が必要
 ◦ 中期的には生産性を維持
 

  9. SimpleとEasyを区別することが大事
 • Easy - Complex
 ◦ 短期的には生産性が高い
 ◦ 中期的には生産性が低下することも 


    
 • Hard - Simple
 ◦ 最初は学習が必要
 ◦ 中期的には生産性を維持
 
 場合によってはこちらの方が重要 
 社内ではこっちを優先したいことも多い 

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


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


  12. 1ライブラリで多種多様なことが実現できる
 • いろいろできるはEasyだけど複雑
 
 • 要素が多くなるほど不要な考慮が増える
 ◦ 使わない機能の競合
 ◦ リリース・更新回数の増加


    ◦ セキュリティリスク
 COMPLEX
 Component A
 Component B
 Component C
 リソース管理
 課金処理
 エディター拡張

  13. コンセプトを明確に・責務を1つに
 • 同タイミングで変更するものはまとめ、異なるものは分ける
 ◦ 閉鎖性共通の原則(単一責任の原則) 
 
 • 適切な名前をつける
 ◦

    名は体を表す
 ◦ 失敗例:社内のGotandaLib(LINQの拡張ライブラリ) 
 SIMPLE

  14. 多くの要素・他のライブラリに依存
 • 依存は複雑
 ◦ 依存の解決や競合
 ◦ 依存ライブラリのメンテナンス状態の考慮 
 
 •

    UPM的な問題もあり
 ◦ Unityにおいてライブラリ間の依存解決にまだ難あり 
 ◦ OSSはOpenUPMで大分いける? 
 COMPLEX

  15. 依存は厳選する
 • 依存先は安定かどうか
 • 公式の機能や標準に依存するのはよい
 ◦ Unity(uGUI, AssetBundle, JsonUtility, WebRequest...)

    
 ◦ .NET (LINQ, Task, Cryptography...) 
 ◦ 社内標準
 • 簡易実装で代替できないかを検討
 ◦ その代わり拡張を用意:後述
 SIMPLE

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


  17. 全シチュエーションにライブラリ側で自動対応
 • 利用側からは何も変更ができない
 ◦ シリアライズ形式、フォーマット
 ◦ ちょっとしたパラメータやステップの付与 
 
 •

    ライブラリへの要求と共に複雑性が増す
 ◦ 新しいフォーマットへの対応は? 
 ◦ 全てに対してメンテナンスできる? 
 ◦ 細かい設定の調整は?
 COMPLEX
 Pattern A
 Impl
 Pattern B
 Impl
 Pattern C
 Impl
 Library
 Core Logic
 My App

  18. 抽象化し拡張できるようにしておく
 • 抽象化したインターフェースを外部に公開
 
 • ライブラリ利用側で拡張を実装
 ◦ 依存注入する
 ◦ ライブラリ側で全て作る必要はない!

    
 
 
 SIMPLE
 Pattern A
 Impl
 Library
 Core Logic
 My App
 My Impl
 <Interface>
 抽象化
 Interface公開
 拡張の実装
 依存の注入

  19. 抽象化し拡張に対して開く
 • 依存注入? for Unity
 ◦ ピュアコード x コンストラクタ、セッターインジェクション 


    ◦ SerializeField
 ◦ SerializeReference
 ◦ GetComponentでInterface探す
 • DIContainer(Extenject/VContainer)
 ◦ ライブラリ側で対応を意識できているとよいですね 
 ◦ 隠蔽しなければ良い
 
 SIMPLE

  20. プレハブを配置すれば自動起動
 COMPLEX
 • MonoBehaviourはEasyだけど複雑
 • 初期化タイミングをコントロールしにくい
 ◦ 任意のシーケンス中に初期化したい 
 ◦

    プレイ中に設定変更して再セットアップしたい 
 • 異なるコンテキストで使いにくい
 ◦ 2種の設定を同時に使いたい
 ◦ テストで使いたい

  21. コアロジックをピュアコード化
 • 色々なコンテキストで利用できる
 ◦ コンストラクタなどに依存や設定を渡す 
 ◦ テストも書きやすい
 
 •

    グローバルなマネージャーやシングルトンパターンは一考
 ◦ ex: MyLibrary.Operation()
 ◦ コンストラクタが隠蔽されます
 
 SIMPLE

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


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


  24. 不要なInterfaceは公開しない
 • 拡張に対して開き・変更に対しては閉じる
 ◦ 全再利用の原則(インターフェース分離の原則) 
 ◦ 開発初期は意識的に絞る・拡張性もあとでいい 
 


    • 最初にテスト/サンプル/Demoをつくる
 ◦ 必要最低限がわかる
 SIMPLE

  25. 超絶UXなエディター拡張
 COMPLEX
 • GUIはEasyだが複雑
 
 • エディターコードもソース・機能の一部
 ◦ メンテナンスが必要
 ◦

    要素が増えれば複雑性は上がる 
 
 

  26. GUIが必要か冷静になって考える
 • そのEasyさ本当に必要ですか?
 
 • EasyじゃないけどSimpleな方法を探す
 ◦ インスペクタの拡張 -> ymlとかjsonとかでデータ読み込み

    
 ◦ セットアップウィザード -> READMEで手順を説明 
 
 SIMPLE

  27. まとめ
 • ライブラリ開発ではSimple / Easyを区別することが大事
 
 • Simpleを保つために
 ◦ 混ぜない・絡ませない


    ◦ 設定や手順を隠蔽しない
 ◦ 提供しすぎない

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