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

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

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

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

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

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

SimpleとEasyの話 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mikito Yoshiya

Other Decks in Programming

Featured

Transcript

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

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

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

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

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

SimpleとEasyの話

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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