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ライブラリの思想と設計〜/simple-unity-library
Search
Mikito Yoshiya
May 26, 2021
Programming
1
740
使われやすいライブラリのための「コ・ツ」〜社内Unityライブラリの思想と設計〜/simple-unity-library
Mikito Yoshiya
May 26, 2021
Tweet
Share
Other Decks in Programming
See All in Programming
Komplexe Oberflächen mit SVG und der Web Animation API
joergneumann
0
680
サイコロで理解する統計的仮説検定の考え方
tatamiya
4
1k
PostmanでAPIの動作確認が楽になった話
h455h1
0
180
Git Rebase
bkuhlmann
11
1.6k
From Spring Boot 2 to Spring Boot 3 with Java 21 and Jakarta EE
ivargrimstad
0
460
Hanami and htmx
bkuhlmann
0
220
Git Lint
bkuhlmann
4
760
Site Reliability Engineering for GMO
pyama86
8
1.1k
Azure OpenAI Serviceのプロンプトエンジニアリング入門
tomokusaba
3
870
Ruby GitHub Packages
bkuhlmann
0
640
Deep Dive into React Stream/Serialize
mugi_uno
3
570
Code Reviews
bkuhlmann
4
900
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
44
6.8k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
275
13k
Designing Experiences People Love
moore
136
23k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
26
2.3k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
Six Lessons from altMBA
skipperchong
22
3k
Art, The Web, and Tiny UX
lynnandtonic
290
19k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.7k
How STYLIGHT went responsive
nonsquared
92
4.8k
What the flash - Photography Introduction
edds
64
11k
Atom: Resistance is Futile
akmur
260
25k
Transcript
使われやすいライブラリの ための「コ・ツ」 社内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
1ライブラリで多種多様なことが実現できる • いろいろできるは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を保つために ◦ 混ぜない・絡ませない
◦ 設定や手順を隠蔽しない ◦ 提供しすぎない
注意 ライブラリ・プラグインにはそれぞれコンセプトがあり、 本資料のアンチパターンが全てに適用されるわけではありません。 あくまで社内ライブラリの選定基準・開発視点でのお話です。