瀕死のシステムが強くなって復活する話

弊社が展開しているタクシー配車サービスにおける乗務員様向けのシステムは今、大きな転換期を迎えています。
約半年に渡って進めてきた、大規模リファクタと開発対象デバイス刷新のプロジェクトがいよいよ陽の目を見るためです。
そんな新システム開発の裏で最低限のメンテしかされず、死にゆく運命にいる現行のシステムがあります。
とあることがきっかけで、今まで想定されていなかった多種多様なユースケースへの対応が必要となり、
現行のシステムにも新たに生まれ変わるチャンスが巡ってきました。

ただし、現在の実装の成熟具合から、現行のシステムを拡張する形での対応は難しく
また大規模に改築するにしても、
平行開発している新システムとのコード的な共存(マルチモジュール)を意識して対応しなければならない状況です。

本セッションでは、上記対応を行った中で学んだ
・多種多様なタクシー乗務のユースケースへ対応するための状態変化に強いアプリアーキテクチャ
・対象端末が違う別のシステムと共存するためのノウハウ
についてお話させて頂きます。

キーワード
- Flux
- MVVM
- マルチモジュール
- ステートマシン
- システムアーキテクチャ

Transcript

1. Yuri Hondo 瀕死のシステムが 強くなって復活する話
2. 自己紹介
 Twitter : URI - @yuyuyuyuyuri URI yurihondo, 本戸 裕理 (ホンド ユウリ) Androidアプリ開発@DeNA MOV 朝早過ぎて息子を保育園へ送る がツライ 2
3. Index
 3 Background for the REVIVAL 1 2 3 4 Current architecture Challenges for REVIVAL New architecture
4. Background for the REVIVAL 1 4
5. 前に 前提を共有させてください 5
9. MOV 紹介 9
10. 乗車位置を指定し タクシーを呼ぶ 10 MOV 紹介
11. タクシー 到着を待つ 11 MOV 紹介
12. タクシーに乗る 12 MOV 紹介
13. タクシーを降りる 13 MOV 紹介
14. • アプリで簡単にタクシーを呼べる • 到着時間がアプリで確認できる • ネット決済利用で車内 支払いが不要 14
15. 乗務員端末 (Android) データ 流れ 15
16. タクシーメーター BLEロガー 乗務員端末 (Android) 後席タブレット (Android) データ 流れ BLE モバイル ネットワーク Wi-Fi Direct MOVサーバー 16
17. タクシーメーター BLEロガー 乗務員端末 (Android) 後席タブレット データ 流れ BLE モバイル ネットワーク Wi-Fi Direct MOVサーバー 17
18. BLEロガー 乗務員端末 (Android) 後席タブレット BLE モバイル ネットワーク Wi-Fi Direct MOVサーバー 18 タクシーメーター タクシーメーター 営業状態 & 運賃
19. 19 空車 迎車 実車 タクシーメーター 支払
20. タクシーメーター BLEロガー 乗務員端末 (Android) 後席タブレット データ 流れ BLE モバイル ネットワーク Wi-Fi Direct MOVサーバー 20
21. ユーザーと 連携 タクシー、ユーザーそれぞれ 位置情報などを仲介 MOVサーバー 21
22. タクシーメーター BLEロガー 乗務員端末 (Android) 後席タブレット データ 流れ BLE モバイル ネットワーク Wi-Fi Direct MOVサーバー 22
23. Remember 2019... 23
24. 24 https://droidkaigi.jp/2019/timetable/70687
25. https://dena.com/jp/press/004421 25
26. できたこと • Flux導入などアーキテクチャ 刷新 • 無線配車対応 26
27. できなかったこと • ステートマシン 分割 • スマホ版とタブレット版 完全な統合 27
28. 28 リプレース
29. つまり 29
31. ...と思っていた ですが 31
32. スマホ版 乗務員アプリ 32
33. こ タクシー配車アプリ戦国時代...? 33
34. タクシー車内 スペース枯渇問題が発生 34
35. スマホ版 乗務員端末にニーズが！！ 35
36. スマホ版 乗務員アプリ 36
37. がしかし 延命治療中 スマホ向け乗務員アプリ 機 能追加がなかなか大変 37
38. さらに 追い討ちをかけるように 38
39. 39 初乗り距離短縮運賃 相乗り運賃 乗合タクシー 相互レイティング 乗り放題タクシー ダイナミック プライシング https://jidounten-lab.com/u_6087
40. スマホ版 乗務員アプリ 40
41. スマホ版 乗務員アプリ 41
42. スマホ版 乗務員アプリ 42
43. スマホ版 乗務員アプリ 43
44. Current architecture 2 44
45. Tablet 45
46. ざっくりクラス図 46
47. ざっくりクラス図 47
48. Flux View Action Creator Dispatcher Store 48
49. 外部から イベント 49
50. 外部から イベント Action Creator メーター 料金が 変わったよ 50
51. 状態 制御 51
52. 状態 制御 Dispatcher App State Activity 状態が 変わったぞぉ 52
53. 状態 制御 Global Actionで ダイアログ出すぞ 53 Activity Dispatcher App State
54. 通知 制御 54
55. 通知 制御 Action Creator 55
56. アーキテクチャ図 56
57. Modules 57
58. Code sample 実車 支払 58
59. AppState Code sample 実車を表すState 59
60. AppState Code sample 支払を表すState 60
61. https://github.com/tomoya0x00/statek#statek 61
62. MainActivity Code sample 支払画面を表示 62
63. Code sample PaymentFragment StoreをBind ActionCreatorを初期化 63
64. PaymentActionCreator Code sample ActionCreator 料金 変更通知 Actionを発行 64
65. PaymentActionCreator Code sample ActionCreator Dispatcherを呼ぶ 65
66. Dispatcher Code sample 66
67. Dispatcher Code sample 67
68. Dispatcher Code sample 指定 クラス み流す 68
69. PaymentStore Code sample 指定 アクションを受け取る 69
70. PaymentStore Code sample LiveDataで公開 70
71. Code sample 支払 71
72. アーキテクチャを刷新してよかったこと • 可読性が向上し、実装で悩むことも減った • マルチモジュールいい感じ • Fluxナウい(ホントか？) 72
73. ちょっときつかったこと • View データ取得タイミング • Flux構造がView毎に別になっている • ActionCreator、Store持たせる情報 精査 73
74. Phone 74
75. ざっくりクラス図 75
76. 神 76
77. 神 77
78. 状態 制御 78
79. 状態 制御 79
80. 状態 制御 80
81. 状態 制御 81
82. 状態 制御 BusinessState Home 82
83. 状態 制御 83
84. 状態 制御 次 状態を細かい粒度で考慮し処 理を行う必要がある 84
85. Code sample 実車 支払 85
86. TaxiBusiness Code sample 86
87. BusinessState Code sample 87
88. Home Code sample 88
89. HomeActivity Code sample 89
90. ちょっとした修正でも 瀕死 状態に ムチを打っている感覚になる 90
91. そして 91
92. スマホとタブレットで アプリ内部 振る舞いが全然違う 92
93. 実態として、 １つ 機能が別々に実装される 93
94. Challenges for REVIVAL 3 94
95. 課題 1. 同じ機能を別々に実装 2. 状態間 忖度 3. 寿命が短いFlux構造 95
96. 1. 同じ機能を別々に実装 96
97. 1. 同じ機能を別々に実装 ➔ 単純に開発工数2倍、着手時期も違う 97
98. 1. 同じ機能を別々に実装 ➔ 単純に開発工数2倍、着手時期も違う ➔ 属人化が冗長し、メンテが大変になっていく 98
99. 2. 状態間 忖度 99
100. 2. 状態間 忖度 ➔ 次 状態を予測した処理を持たざる得ない 100
101. 2. 状態間 忖度 ➔ 次 状態を予測した処理を持たざる得ない ➔ １つ 状態が肥大化していく 101
102. 3. 寿命が短いFlux構造 102
103. 3. 寿命が短いFlux構造 ➔ View毎にActionCreator、Storeが存在 103
105. 1. 同じ機能を別々に実装 2. 状態間 忖度 3. 寿命が短いFlux構造 課題 105
106. 解決方法 • PhoneへFlux適用 Application層までを統合しUI層をApp毎に実装 106
107. Application presentation Phone Tablet 107 View Action Creator Store View Action Creator Domain Store Dispatcher Repository StateMachine Hoge
108. 1. 同じ機能を別々に実装 2. 状態間 忖度 3. 寿命が短いFlux構造 課題 108
109. 1. 同じ機能を別々に実装 2. 状態間 忖度 3. 寿命が短いFlux構造 課題 StateMachine 切り出し 109
110. 1. 同じ機能を別々に実装 2. 状態間 忖度 3. 寿命が短いFlux構造 課題 110
111. 1. 同じ機能を別々に実装 2. 状態間 忖度 3. 寿命が短いFlux構造 課題 画面単位から営業単位に伸 す 111
112. 解決方法 • 営業状態毎にStateを分離 タクシー自体 営業サイクルと 利用者毎に変わる営業サイクルを分離する 112
113. 113 状態 分離
114. 114 状態 分離 移譲
115. 115 状態 分離 AppState BusinessState ＞
116. Navigation 116 ログイン 画面 空車 画面 Router 流し乗車 事前確定 アプリ配車 アプリ配車 hoge配車
117. Navigation 117 ログイン 画面 空車 画面 Router 流し乗車 事前確定 アプリ配車 アプリ配車 hoge配車
118. 解決策まとめ • PhoneへFlux適用 • 営業状態毎にStateを分離 118
119. New architecture 4 119
120. ざっくりクラス図 120
121. ざっくりクラス図 121
122. ざっくりクラス図 122 BusinessState ActionCreator
123. アーキテクチャ図 123
124. アーキテクチャ図 124
125. モジュール構成 125
126. モジュール構成 126
127. Navigation 127
128. Navigation 128
129. Navigation 129
130. Code sample 130
131. Code sample 配車依頼 131 事前確定 支払
132. RouterBusinessFragment Code sample 132
133. DeliverMapFragment...etc Code sample 133
134. PreReportedFareActionCreator Code sample 134
135. PreReportedFareActionCreator Code sample 135
136. PreReportedFareBusiness Code sample 136
137. // TODO: 137
138. これからやっていきたい事 • UI/UX 調整 • AppState Scopeを絞りたい • 138
139. 139 Thanks