MTC2018 - High-Performance Android - US App: Evolution

Speaker: Atsuko Fukui, Matthew Vern

2018 was a year of big changes for the Mercari US Android team. In 2017, the team had only three members spanning the Tokyo and San Francisco offices and was small but efficient; in 2018, the team has doubled in size. As a result, the team has moved from a Public Security Section 9 model, where the strengths of each individual were the focus, to a stage where they are aiming for different strengths across the teams in each country. In this session, the Mercari US team will talk about their unique choice of technologies and approach to teamwork across the Tokyo and Palo Alto offices in their effort to maintain a high level of performance while faced with the challenges of distance and time differences.

Transcript

1. High-Performance Android - US App: Evolution Atsuko Fukui Software Engineer (Android) Matthew Vern Software Engineer (Android)
2. Software Engineer Android Atsuko Fukui Software Engineer Android Matthew Vern
3. High Performance Android: EVOLUTION
4. Summary - The US Mercari Android team is growing rapidly - What are we implementing to ensure we win this battle?
5. History of the US Android Team
6. Section 9 Model We don’t have the convenient excuse of relying on team plays. The closest thing we have is the teamwork born from strong single plays. “ ” Chief Daisuke Aramaki, 2002 (Ghost in the Shell S.A.C)
7. US Mercari Android Team
8. US Mercari Android Team Joined! (Feb 2018) Joined! (Jan 2018)
9. US Mercari Android Team US@Tokyo team US@Palo Alto team
10. Team x Team
11. Team Challenge - Team size is expected to surpass 100 members in the next few years - Producing a high quality product at explosive speed, regardless of team timezones & distance
12. Tasks
13. 3 Main Issues Scalability Ownership ・Increasing practical knowledge, and personalized specs ・Catch-up costs required by the increasingly complex code ・Communication costs and delays caused by remote offices ・Not enough dividing of technical roles Quality ・Increasing code quality and productivity ・Dealing with vulnerabilities
14. 3 Solutions! Scalability Ownership Quality
15. 3 Solutions! Scalability Ownership Quality
16. Flux
17. Scalability Ownership Quality Flux
18. ~2017 Architecture - MVVM - Aimed to ensure everyone could write the same code View View Model Service Repository
19. MVVM - ViewModel has too much responsibility - Retrieving data from Service layer - Processing data to send to the View View View Model Service Repository
20. MVVM - ViewModel becomes fat quickly due to holding the interfaces to handle events, as well as returning data View View Model Service Repository
21. MVVM
22. MVVM Problems - Problems from increased complexity and expansion - Having new members catch up with the specs can take a lot of time - Conducting reviews remotely is difficult Potential problems caused by team growth and scaling
23. MVVM Problems - Problems from increased complexity and expansion - Having new members catch up with the specs can take a lot of time - Conducting reviews remotely is difficult Potential problems caused by team growth and scaling Let’s Flux
24. What is Flux? - Originally an Architecture designed for React (Web Front-end) applications - Built by Facebook - https://github.com/facebook/flux
25. About Flux - Unidirectional data flow - Action -> Dispatcher -> Store - Simple data flow - Store is only updated by Actions
26. Flux on our architecture View View State Modify data Action ( from ActionCreator) Dispatcher Store Flowable Completable Void
27. Unidirectional data flow Each classes responsibility is clear, so readability is improved Can hit the ground running Reviewing code is easier
28. Simple data flow The State is only updated via Actions, so the data flow is easy to understand Remove complication Ensure scalability
29. Modularize
30. Scalability Ownership Quality Flux Modularize
31. ~2017 Monolithic System - Build time increases as features are added - Difficult to judge the scope of any single feature
32. Monolithic App
33. Monolithic App • Camera • Checkout • Detail • Experiment • Featured • Home • Inbox • Interest • Login • Notification • Profile • etc...
34. Monolithic App • Camera • Checkout • Detail • Experiment • Featured • Home • Inbox • Interest • Login • Notification • Profile • etc...
35. Monolithic - As code and features increased, build times doubled compared to 6 months prior - All the code was contained in one module, and so it was difficult to read the dependency graph
36. Monolithic - As code and features increased, build times doubled compared to 6 months prior - All the code was contained in one module, and so it was difficult to read the dependency graph Let’s Modularize
37. Modularize - Create modules per feature
38. Modularize App
39. Modularize App Camera Experiment Home Inbox Notification Login
40. Modularize App Camera Experiment Home Inbox Notification Login
41. Modularize App Camera Experiment Home Inbox Notification Login
42. Modularize results - Build speed doesn’t increase even when adding new features - Dependency graph becomes easier to read
43. 画像や写真 - Modularizing ProtocolBuffer models
44. 画像や写真 - Modularizing ProtocolBuffer models - Build time decreased by 25%
45. Kotlin
46. Scalability Ownership Quality Flux Modularize Kotlin
47. Kotlin? - Developed by JetBrains - Runs on the JVM - Strongly typed language
48. Kotlin - 4.1% → 45.4% - More Kotlin than Java
49. Kotlin merits - Easier to read intention of code - Amount of code decreases
52. Kotlin - build.gradle → build.gradle.kts - Anything that can be written in Kotlin, will be - Can use ktlint to improve the quality of our buildscripts as well
53. Summary
54. Flux ・Ensure scalability by 　reducing code 　complexity and 　preventing code bloat ・Eliminating 　unnecessary 　dependencies ・Make feature 　ownership clear ・Increase product 　quality Modularize Kotlin Scalability Scalability Ownership Quality
56. We’re creating an environment where we can support a 100-member Android team
57. Will you be our 6th?