MTC2018 - High 意識 Android - US App : Evolution

Speaker: 福井 敦子, Matthew Vern

2018年、US Androidチームは大きな変革を遂げました。2017年はTokyo & San Francisco 合わせて3人体制という極少数精鋭チームで走り切りましたが、2018年、ついにメンバーの数が倍になりました。これにより、個々人の能力に重点を置いていた「公安9課モデル」から、チーム x チーム で更なる高みを目指すステージに移ったのです。時差や距離といった制約の中でより高いパフォーマンスを追求し続けながら、Tokyo & Palo Altoの2拠点で開発を進めるMercari USチームならではの技術選定とチームワークについて、お時間の許す限り紹介します。

Transcript

1. High 意識 Android - US App : Evolution 福井 敦子 Software Engineer (Android) Matthew Vern Software Engineer (Android)
2. Software Engineer Android Atsuko Fukui Software Engineer Android Matthew Vern
3. High意識Android US App : EVOLUTION
4. Summary - USのMercari Androidアプリ開発チームの成長 - チーム戦で勝つための取り組み
5. これまでのUS Android Team
6. 公安 9 課モデル 我々の間にはチームプレイなどという 都合のよい言い訳は存在せん。 あるとすればスタンドプレーから生じる、 チームワークだけだ。 “ ” 荒巻大輔, 2002 (攻殻機動隊 S.A.C)
7. US Mercari Android Team
8. US Mercari Android Team Joined! (2018.2 ~) Joined! (2018.1 ~)
9. US Mercari Android Team US@Tokyo team US@Palo Alto team
10. チーム x チーム
11. チームでの挑戦 - 数年後は100人を超える大規模チームを想定 - 時差と距離に負けず、爆速・高品質なプロダクトを提 供
12. 課題
13. 取り組むべき課題の整理 スケール オーナーシップ ・暗黙知、属人化した仕様の増加 ・コードの複雑化によるキャッチ　 アップコスト ・海をまたぐことによるコミュニ　ケー ションコストや開発の遅延 ・技術的な役割分担の不足 品質 ・コードの品質や生産性の向上 ・脆弱性への対応
14. 3つの道具で解決！ スケール オーナーシップ 品質
15. 3つの道具で解決！ スケール オーナーシップ 品質
16. Flux
17. スケール オーナーシップ 品質 Flux
18. 2017年までのArchitecture - MVVM - 誰でも同じコードがかけることを目的としていた View View Model Service Repository
19. MVVM 課題 - ViewModelの責任範囲が広く複雑化 - Serviceからのデータの受け取り - Viewへ渡すデータの加工 View View Model Service Repository
20. MVVM 課題 - イベントを受けるインターフェイス、ストリームを返すイ ンターフェイスを持つので肥大化 View View Model Service Repository
21. MVVM
22. MVVM 課題 - 複雑化・肥大化が問題に - 新規メンバーの仕様のキャッチアップに時間がか かる - リモートでのコードレビューがつらい 今後メンバーが増えてチームがスケールすると問題になる 可能性
23. MVVM 課題 - 複雑化・肥大化が問題に - 新規メンバーの仕様のキャッチアップに時間がか かる - リモートでのコードレビューがつらい 今後メンバーが増えてチームがスケールすると問題になる 可能性 そこで Flux
24. Fluxとは - もともとReact (Web Front-end) 向けのApplication Architecture - Facebookが開発 - https://github.com/facebook/flux
25. Fluxの特徴 - 単方向のデータフロー - Action -> Dispatcher -> Store - フローがシンプル - StoreはActionによってのみ変更される
26. Flux on our architecture View View State Modify data Action ( from ActionCreator) Dispatcher Store Flowable Completable Void
27. 単方向の データフロー 各クラスの責務が明確なので 可読性が高い キャッチアップしやすい コードレビューがしやすい
28. フローが シンプル StateはActionによってのみ変 更されるのでフローがシンプル 複雑化の解消 スケーラビリティの担保
29. Modularize
30. スケール オーナーシップ 品質 Flux Modularize
31. 2017年までのMonolithic System - Feature増えたらビルド時間が長くなる - 一つのfeatureの範囲は分かりづらくなる
32. Monolithic System App
33. Monolithic System App • Camera • Checkout • Detail • Experiment • Featured • Home • Inbox • Interest • Login • Notification • Profile • etc...
34. Monolithic System App • Camera • Checkout • Detail • Experiment • Featured • Home • Inbox • Interest • Login • Notification • Profile • etc...
35. Monolithic System - コードと機能が増えて、6ヶ月前と比較してコンパイル 時間が倍になった - すべてのコードが同じモジュールに入っているので機 能間の依存が分かりにくい
36. Monolithic System - コードと機能が増えて、6ヶ月前と比較してコンパイル 時間が倍になった - すべてのコードが同じモジュールに入っているので機 能間の依存が分かりにくい そこで Modularize
37. Modularize System Featureごとにmodule分ける
38. Modularize System App
39. Modularize System App Camera Experiment Home Inbox Notification Login
40. Modularize System App Camera Experiment Home Inbox Notification Login
41. Modularize System App Camera Experiment Home Inbox Notification Login
42. Modularize効果 - Feature増えてもビルド時間は増えない - 依存関係が分かりやすくなる
43. 画像や写真 - ProtocolBufferのモ デルをmodule化
44. 画像や写真 - ProtocolBufferのモ デルをmodule化 - ビルド時間25%減らし た
45. Kotlin
46. スケール オーナーシップ 品質 Flux Modularize Kotlin
47. Kotlinとは - JetBrains社が開発 - JVM上で動く - 強い型付け言語
48. Kotlin - 4.1% → 45.4% - Javaより多くなった
49. Kotlin化のメリット - コードの意図が分かりやすくなる - コード量が減る
52. Kotlin - build.gradle → build.gradle.kts - Kotlinで書けるものは全部Kotlinで書く - ktlintもかけて、buildscriptのコードの品質でも上げよう としている
53. まとめ
54. Flux ・コードの複雑 化・肥大化を 防ぎ、スケーラ 　ビリティを担保する ・不要な依存関係を 排除出来る ・各featureの 　ownershipが明確に 　なる ・プロダクトの品質が 上がる Modularize Kotlin スケール スケール オーナーシップ 品質
56. Androidチーム100人でもス ケール出来るような 環境を作っていく
57. 6/100人目になりませんか？