新タクシー配車システムの裏側/dispatcher-background

Transcript

1. 新タクシー配車システムの裏側 2017-05-23 : ヒカラボ発表資料 JapanTaxi : 相田 岳彦
2. 自己紹介 2016-06 JapanTaxi 入社 06-07 月 某 API サーバ / Golang 07-11 月 全国タクシー Android / Java 10-12 月 Google Maps 対応 12-01 月 某バッチサーバ / Scala 12-02 月 全国タクシー API / Rails 03 月- 新タクシー配車システム / ES6, Rails いろいろやってます
3. 今回話すこと 新タクシー配車システムの紹介 技術的負債を避けるための取り組み Rails API 開発編 React フロントエンド開発編
4. 今回話さないこと Rails や React アプリの構築方法 CI/CD の構築方法
5. そもそも配車システムって何さ ざっくりまとめると
6. お客さんからの注文を受けて オペレータが空車状況などを確認して タクシーを配車するためのシステム
7. 今回話すところ API は Rails で作られていて フロントは React で作られているサービス
8. ということで技術的な話
9. まずは Rails の話から
10. Rails 開発で防いでおきたかったこと とりあえず ID パターン テーブルモデル中毒
11. とりあえず ID パターン ( ご存知の方)
12. あらゆるテーブルに ID を入れてしまう症状 詳細は "SQL アンチパターン" 参照
13. 大前提 ウェブフレームワークの都合で テーブル設計を歪める判断は基本的にありえない
14. 対処 Rails にはきちんと primary key を 明示する仕組みが用意されてる
15. Q. そうはいっても "id" がないと 冗長になるコードはあるよね？ A. それでもプロダクト根幹の DB 設計を歪めるほうがダメ
16. テーブルモデル中毒 ( ご存知の方)
17. 先週名付けました ( 聞いたことがなくても安心してください)
18. テーブルと 1:1 で紐付いた「モデル」で 全てを表現しようとする症状
19. 行き着く先は 典型的なファットモデル… ！
20. これが rails-way なのだという誤解を 頻繁に見かける超要注意パターン
21. テーブルモデル中毒を 予防するには… ？
22. レビューで解決… ？ レビュアーが全員 毎回忘れずに チェックするのは現実的だろうか（反語）
23. 開発者全員が危険性と 回避方法を理解すればいい… ？
24. しかし未経験の負債への対処はとても難しい ファットモデルのヤバさは ファットになるまで気付けない ファットになってしまったら もうすでに遅かったりして…
25. あらためて テーブルモデル中毒を 予防するには一体どうしたら… ？
26. 私たちの答え 「モデリングを開発フローに組み込もう」
27. 具体的には？ アクションごとの仕様を宣言するための 言語内 DSL をコントローラに用意
28. 個々のリクエストとレスポンスに 対応するクラスをまず最初に定義する それぞれのクラスに対応する JSON Schema ファイルも生成する
29. コード例 update アクションの仕様を宣言する場合 api :update, :request => Requests::V1::Hello::CreateParameter :response => Resources::V1::Greeting::Hello
30. これによって テーブルモデルを引き回すコードや view で巨大な JSON を構築するようなコード が生まれてしまう余地を取り除いた
31. さらに 指定した型にならないリクエストは 400 指定した型にならないレスポンスは 500 も自動化できた！
32. 副次的な効果
33. JSON Schema を導入したことで : API 仕様が自動的にバージョン管理される うっかり破壊的変更を入れても簡単に気付ける （スキーマファイルも変更されるため）
34. リソースのモデリングによって : リソースの型をバージョニングできる 安全にバージョンアップできる 機能拡張に対する心理的障壁の除去
35. 言語内 DSL の表現力によって リソースを今まで通りに抽象化できる JSON Schema の手作業記述を回避 正規表現のコピペ問題なども回避
36. 次は React の話 というよりは React-Redux の話
37. React-Redux で防いでおきたかったこと implicit state implicit action fat dispatcher
38. implicit state 実装者の頭の中だけに state の定義がある状態
39. implicit state 「どのような状態が正しいのか」が コードで表現されていない状態 フィールドの更新漏れ・追加忘れといった 人的ミスが誘発される
40. 解決方法 全ての state をクラスとして明示的に定義 初期状態や更新方法をクラス内で完結させる
41. implicit action 実装者の頭の中だけに action の定義がある状態
42. implicit action 「この action にはどのような値があるのか」 「この action はどの type と紐付いているのか」 抱えている問題は implicit state とほぼ同じ
43. 解決方法 対処策も implicit state とほぼ同じ ( ただし action の場合はクラス化の必要なし)
44. 具体的には… ？ action と type を紐付ける ActionFactory を用意
45. これによって : factory に action の定義が明文化される reducer の依存先を action-factory だけにできる 文字列定数の type を羅列する苦行の回避
46. コード例 actions.js // 該当する顧客が見つかった場合のアクション export const CustomerFound = ActionFactory({ type: 'OrderEditor/CustomerFound', /** * @param {CustomerOutline} customer */ currentCustomer: customer => customer, });
47. reducer.js // 注文編集フォームの reducer export const editorReducer = ReducerFactory.create({ initializer: () => { return EditorState.empty(); }, /** * @param {EditorState} state * @param {Object} action - see ./actions.js */ handlers: (state, action) => ({ [CustomerFound]: () => { return state.updateState({ customer: action.currentCustomer, }); }, }), ... });
48. fat dispatcher 文字通り dispatcher が肥大化する症状 fat model や fat controller と同種のもの
49. 解決方法 dispather の責務を絞る
50. 具体的には？ dispatcher は 文字通り action を dispatch するだけに留める 各種データの取得処理は他のモジュールに切り出す 典型例は API リクエスト レイヤードアーキテクチャを導入して責務を分担
51. レイヤー構造 layouts 画面内の component に紐づく処理 domain 複数の component で共有するロジック repository API リクエスト ストレージ (cookie, LocalStorage) 操作 dispatcher が利用する多くのモジュールは ほとんどの場合はこのレイヤにある （相対パス地獄は webpack の resolve.root 指定で回避）
52. まとめ Rails Rails Way をダメな設計の弁明手段にしない ダメなのは必ずしも Rails のせいではない React (Redux) サンプルコードはそのまま真似してはいけない プロジェクトに適した方法で抽象化しよう - n-