bitbankの中規模Angularアプリケーションを再設計し、パフォーマンスの改善やメンテナンス性の向上を試みている話について発表します。

1. 中規模Angularアプリケーションの
再設計
Suguru Inatomi
bitbank LT Night #5

2. © bitbank inc.
2
Suguru Inatomi
@laco2net

3. 今日のアジェンダ
3

4. © bitbank inc.
アジェンダ 4
● アーキテクチャ導入の話
● パフォーマンス改善の話
● 品質改善の話

5. アーキテクチャの話
5

6. 課題なきアーキテクチャは
ただのアート
6

7. © bitbank inc.
bitbankアプリの大きな課題 7
● 状態管理の分散
○ Serviceごとに管理の仕方がバラバラ
● ビジネスロジックの点在
○ コンポーネントがロジックを持っている

8. © bitbank inc.
願望 8
● 状態管理の分散
○ 状態管理を一元化したい
● ビジネスロジックの点在
○ コンポーネントから切り出してまとめたい
○ 適切にモジュール分割したい

9. 願望を叶えるための
構造を考える
9

10. © bitbank inc.
中規模Angularアーキテクチャ v1.1 10

11. © bitbank inc.
ベースになる原理原則 11
● Presentation Domain Separation (PDS)
○ プレゼンテーションとドメインの分離
● Single Responsibility Principle (SRP)
○ 単一責任の原則
● Stable Dependencies Principle (SDP)
○ 安定依存の原則
● Command Query Responsibility Segregation (CQRS)
○ コマンド・クエリ責務分離
● Single source of truth (SSOT)
○ 唯一の情報源

12. © bitbank inc.
つまりどういうこと？ 12
● Presentation Domain Separation (PDS)
○ コンポーネントからビジネスロジックを切り出す
● Single Responsibility Principle (SRP)
○ サービスの役割を明確にして境界づける
● Stable Dependencies Principle (SDP)
○ ユースケース依存のモジュールとそうでないものを境界づける
● Command Query Responsibility Segregation
○ 状態を変更する経路を限定する
● Single source of truth
○ アプリケーションの状態を一元管理する

13. © bitbank inc.
Presentation Domain Separation 13
Presentation系とDomain系を分離

14. © bitbank inc.
Single Responsibility Principle 14
役割ごとにモジュールを分類

15. © bitbank inc.
Stable Dependencies Principle 15
より安定しているモジュールに依存する

16. © bitbank inc.
Command Query Responsibility Segregation 16
WriteOnlyのUsecaseと
ReadOnlyのQueryを
Componentが利用する

17. © bitbank inc.
Single source of truth 17
アプリケーションの状態は
Storeで管理する

18. © bitbank inc.
Usecase-Store-Query 18
● Storeの実装として @ngrx/store を採用

19. © bitbank inc.
NgRxと学習曲線の設計 19
● NgRxへの関心をStore層に閉じる
○ NgRxから別のライブラリに変えやすくする
○ NgRxを知らなくても開発に参加できるようにする
● 参考: システムの学習曲線とAngularアプリケーションの設計

20. © bitbank inc.
Work in Progress 20
● Presentationのモジュール化はがんばりすぎない
○ 効果が薄い
● PDSができたら60点（可）
○ PDSさえ出来ていればどうとでもなる
● Webのことだけ考える（bitbankの場合）
○ locationやwindowの抽象化に固執しない
● TypeScriptとして簡潔であることを重視する
○ AngularやRxJSを使いこなそうとしない

21. 小休止
questions$
.pipe( takeUntil( timer(3分) ) )
.subscribe()
21

22. パフォーマンス改善の話
22

23. © bitbank inc.
やったこと 23
● バンドルサイズの削減
○ main.bundle.js: 1.96MB -> 1.29MB (gzip前)
● 一部CSSのインライン化
○ 起動前のローディング用のCSS

24. © bitbank inc.
バンドルサイズの削減内訳 24
● 脱lodash ( => lodash.XXX )
● 脱moment ( => dayjs )
● 脱SharedModule
● Angular v8.0 (Differential Loading)
○ 参考

25. © bitbank inc.
バンドルサイズ推移 25

26. © bitbank inc.
初期CSSのインライン化 26
● ローディングアニメーション用のCSS
● CSSのロードが終わるまでローディングが出なかった
● index.htmlにハードコード
○ ほぼ変わることのない部分
○ HTMLのサイズはそれほど問題ではない

27. © bitbank inc.
留意点 27
● bitbankのアプリの特殊性
○ ほぼ検索流入しない
○ リアルタイムデータ依存（SSRしない）
● 初期ロードパフォーマンスの重要度: 低
● アーキテクチャを犠牲にしてまで高速化するモチベーションはない
○ あるべき形でそれ相応のパフォーマンスであればOK

28. 品質改善の話
28

29. © bitbank inc.
品質とは？ 29
● バグが少ないアプリケーションを目指す
● アプリケーションの入口と出口で品質を担保する
○ 入口: デプロイ前にバグを除去する = テスト
○ 出口: デプロイ後にバグを検知する = 監視

30. © bitbank inc.
アプリケーションの監視 30
● エラーの発生を検知する
○ ツール: Sentry
● 検知できた例
○ リリース後に特定のブラウザでエラーが起きていた
■ Polyfill不足
○ `Cannot read property *** of undefined`
■ TypeScriptの型定義漏れ (Null Check)

31. © bitbank inc.
ノイズが多い問題 31
● どんなエラーも全部流れてくる
○ アプリケーション側でハンドルすべき例外
○ サードパーティJSがグローバルに投げるエラー
● 監視を運用するにはノイズを除去する必要がある
○ Slack通知が多すぎる
● 取り組み
○ 例外処理の見直し
○ HTTPリクエストにリトライを導入
○ 通知すべきエラーのフィルター設定

32. まとめ
32

33. © bitbank inc.
Takeaway 33
● アーキテクチャは割り切りとコスパが大事
○ 例:「PDSさえできてれば合格」
● 守破離。まずは歴史に学び、原理原則を知る
● moment.jsやlodashの利用は計画的に
● SharedModuleが許されるのは小規模アプリまで
● アプリケーションの監視は重要
○ 実行時エラーに気づける仕組みを作る