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
710
使われやすいライブラリのための「コ・ツ」〜社内Unityライブラリの思想と設計〜/simple-unity-library
Mikito Yoshiya
May 26, 2021
Tweet
Share
Other Decks in Programming
See All in Programming
phpunit/php-code-coverageって何をしてるんだ #phperkaigi
o0h
PRO
2
190
スタートアップのフロントエンド事情 GENBA #2 〜Front-End Opsの現場〜
ebijun1007
1
780
オレオレkaggle開発環境に Formatter/Linter入れてみた
stgkrt
0
350
TerraformをやめてCDKでReStartしたあと、 CDKをやめてCDK for TerraformでReStartした話
tmiura0203
0
770
TDDと今まで
kanayannet
0
110
Deno に Web 標準 API を実装する / Implementing Web Standard API to Deno
petamoriken
0
310
Cloudflare Workersの環境を再現することについて
yusukebe
5
720
Learning Ruby
okuramasafumi
5
370
Flutterアプリを GitHub Actions & Xcode Cloud で社内配布する / Distribute Flutter apps internally
takasfz
0
120
Apple Vision Pro購入RTA 1泊3日弾丸ハワイツアー / RTA: Purchase Apple Vision Pro in Hawaii
yutailang0119
0
480
ファイル先頭の use の意味、説明できますか? 〜PHP の namespace と autoloading の関係を正しく理解しよう〜 / namespace and autoloading in php
okashoi
2
390
期限が近づいてきた!Privacy Manifests対応
ryunakayama
5
3k
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
72
8.1k
The Invisible Side of Design
smashingmag
293
49k
The Art of Programming - Codeland 2020
erikaheidi
40
12k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
18
6.8k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
39
4.3k
Art, The Web, and Tiny UX
lynnandtonic
288
19k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
11
1.4k
Large-scale JavaScript Application Architecture
addyosmani
501
110k
What's new in Ruby 2.0
geeforr
335
31k
Debugging Ruby Performance
tmm1
68
11k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
240
1.2M
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を保つために ◦ 混ぜない・絡ませない
◦ 設定や手順を隠蔽しない ◦ 提供しすぎない
注意 ライブラリ・プラグインにはそれぞれコンセプトがあり、 本資料のアンチパターンが全てに適用されるわけではありません。 あくまで社内ライブラリの選定基準・開発視点でのお話です。