The state patternの実践 個人開発で培ったpractice集

For: すごくすごい。フロントエンドミートアップ 〜複雑GUI・アーキテクチャ設計を語ろう〜
https://formx.connpass.com/event/364158/

Transcript

1. The state patternの実践 個人開発で培ったpractice集
2. Intro 1. The state patternとは? 2. Practice 1: State分割中心設計 3. Practice 2: 共通化 < 並行化 4. Practice 3: 同期的なstate遷移 @robokomy 右みたいなのが年々増えてます Agenda
3. The state patternとは?
4. The state patternとは? Refs: https://gameprogrammingpatterns.com/state.html https://refactoring.guru/ja/design-patterns/state The state patternとは? • デザインパターンの1つ（≠フロントエンド文脈の一般的なstate） • ゲーム開発における定番手法 State · Design Patterns Revisited このLTを届けたい人たち • ユーザー操作が複雑なGUIを実装したことがある人 • 最初は順調だったそのコードが複雑になりすぎて何も分からなくなった人 • 作図・お絵かき的なツールを育てていきたい人
5. Practice 1: State分割中心設計
6. Practice 1: State分割中心設計 • 例: ラインを描画する一連の操作 • 制御用の状態は増え続ける • 操作の数だけ状態は積み上がる • 状態の遷移に基づく分割統治 • 各stateは独立した存在 効果: 処理と状態のスコープが小さくなり見通しが良くなる 複雑GUIを破綻させずにスケールアップするための強力なデザイン
7. Practice 2: 共通化 < 並行化
8. Practice 2: 共通化 < 並行化 • 似たstateをコピペ量産することを恐れない ◦ 各stateは独立しているのでシステムの複雑度は高々その state分増えるだけ ◦ そのstateを更新しない限り新たな複雑さはもたらさず、更新したとしても高々その state分 の複雑さに留まる ◦ バグ対応などで修正箇所が多い分の手間は増えるが手間は安い。型補助もあるし AIもあ る • コピペ量産の果てに共通化あり ◦ 早すぎた不適切な共通化はシステムの複雑度を一気に増やす（関連 state数で乗算） ◦ 共通化された部分に手を加える度に新たな複雑さは関連 state数で乗算される ◦ コピペコードの共通化は手間だが AIの得意分野 • Class断固拒否（諸説あり） ◦ Classあるところに継承あり ◦ 継承してちょちょいとフラグと分岐を追加しての最小コードで済ませる誘惑に人類は打ち勝 てない 効果: システムの複雑度が眼前のコード量以上に増えない State更新時の複雑度イメージ
9. Practice 3: 同期的なstate遷移
10. Practice 3: 同期的なstate遷移 • ユーザーイベントをハンドリングした結果と して次のstateをreturnする設計 • 同期的な遷移に作り変え ◦ 同期な世界で完結するシンプルコード ◦ 隙間が発生しないスムーズな state遷移とライフサイクル • 非同期なstate遷移は脱出ハッチ的な後付実現可能 • 柔軟さ考慮で最初は非同期を採用したが様々な問題に遭遇 ◦ コードが冗長（影響小） ◦ ユーザーイベントがPromise解決の隙間に落ちて stateのライフサ イクルを逸脱した動作を引き起こす（影響大） • 非同期なstate遷移が必要な場面に全く遭遇せず無活躍 効果: 全体の98%を占める同期的state遷移が非常にシンプルになる
11. Thanks!