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...
Search
Mikito Yoshiya
May 26, 2021
Programming
1
920
使われやすいライブラリのための「コ・ツ」〜社内Unityライブラリの思想と設計〜/simple-unity-library
Mikito Yoshiya
May 26, 2021
Tweet
Share
Other Decks in Programming
See All in Programming
AI駆動のマルチエージェントによる業務フロー自動化の設計と実践
h_okkah
0
180
チームのテスト力を総合的に鍛えて品質、スピード、レジリエンスを共立させる/Testing approach that improves quality, speed, and resilience
goyoki
5
960
코딩 에이전트 체크리스트: Claude Code ver.
nacyot
0
810
NPOでのDevinの活用
codeforeveryone
0
860
Goで作る、開発・CI環境
sin392
0
240
ニーリーにおけるプロダクトエンジニア
nealle
0
880
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
1
6.3k
ふつうの技術スタックでアート作品を作ってみる
akira888
1
930
ご注文の差分はこちらですか? 〜 AWS CDK のいろいろな差分検出と安全なデプロイ
konokenj
3
290
Node-RED を(HTTP で)つなげる MCP サーバーを作ってみた
highu
0
120
おやつのお供はお決まりですか?@WWDC25 Recap -Japan-\(region).swift
shingangan
0
140
Result型で“失敗”を型にするPHPコードの書き方
kajitack
5
950
Featured
See All Featured
Embracing the Ebb and Flow
colly
86
4.7k
We Have a Design System, Now What?
morganepeng
53
7.7k
Become a Pro
speakerdeck
PRO
29
5.4k
Documentation Writing (for coders)
carmenintech
72
4.9k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
The Language of Interfaces
destraynor
158
25k
Done Done
chrislema
184
16k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
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を保つために ◦ 混ぜない・絡ませない
◦ 設定や手順を隠蔽しない ◦ 提供しすぎない
注意 ライブラリ・プラグインにはそれぞれコンセプトがあり、 本資料のアンチパターンが全てに適用されるわけではありません。 あくまで社内ライブラリの選定基準・開発視点でのお話です。