Modularization - How hard can it be? (Droidcon London 2018)

Recording can be found here: http://uk.droidcon.com/skillscasts/12186-modularization-how-hard-can-it-be

Modularizing Android codebases is all the hype these days. It can be as simple as moving a few files, and maybe creating a new build config or two along the way, or it can be much more gruelling. At Spotify, it has meant clearing out years and years of tech debt, re-writing APIs, rethinking the architecture and structure of the application and features that goes into it, wrestling with build tools, and then some.

This talk will walk you through the Spotify modularization journey: why we got started, how we went about it, what we have learned through the process, and also why you should be thinking about modularizing your code, if you haven't already started.

Links shared in the presentation:

Instagram: https://atscaleconference.com/videos/app-modularization-and-module-lazy-loading/
Square: https://youtu.be/GesiS2bkTKA
Yelp: https://engineeringblog.yelp.com/2018/06/how-yelp-modularized-the-android-app.html
Soundcloud: http://uk.droidcon.com/skillscasts/10525-modularizing-android-applications
Google: https://youtu.be/tYf9ivnQ0eI
Plaid: https://medium.com/androiddevelopers/a-patchwork-plaid-monolith-to-modularized-app-60235d9f212e
Spotify (previous, slightly different version of this talk): https://youtu.be/opsiSaUS2bg

Transcript

1. Modularization How hard can it be? Elin Nilsson @hejelinnilsson
2. Modularization How hard can it be? Elin Nilsson @hejelinnilsson
3. Very!
4. It’s complicated
5. Modularization is a hot topic Instagram Square Yelp Soundcloud Google Plaid Spotify
6. What I will NOT talk about
7. What I WILL talk about
8. The Spotify Modularization Journey
9. Why?
10. History
11. Growing Growing Growing Growing
12. 100+ devs, 50+ teams, 5 cities
13. Growing Growing Growing Slowing
14. Let’s modularize!
15. How?
17. one feature outside of the monolith 1st
18. one feature outside of the monolith 1st 1. Come up with a module structure
19. :app :http :logg er :audi o :vide o :arti st :sear ch :ui :radi o :rxja va :dag ger :dep -inj
20. :app
21. :app :features :common :libs
22. :app :features :common :libs :http :logger :audio :video :artist :search :ui :library :feed :profile :radio :radio :android :ui-tools :follow :share :mobius :dep-inj
23. one feature outside of the monolith 1st 1. Come up with a module structure
24. one feature outside of the monolith 1st 1. Come up with a module structure 2. Create some modules
25. one feature outside of the monolith 1st 1. Come up with a module structure 2. Create some modules a. Dependency management!
26. one feature outside of the monolith 1st 1. Come up with a module structure 2. Create some modules a. Dependency management! 3. Put stuff in the modules
27. one feature outside of the monolith 1st 1. Come up with a module structure 2. Create some modules a. Dependency management! 3. Put stuff in the modules a. Analyse dependencies
28. one feature outside of the monolith 1st 1. Come up with a module structure 2. Create some modules a. Dependency management! 3. Put stuff in the modules a. Analyse dependencies b. Break dependencies
29. one feature outside of the monolith 1st 1. Come up with a module structure 2. Create some modules a. Dependency management! 3. Put stuff in the modules a. Analyse dependencies b. Break dependencies i. Works? Great! Move it!
30. one feature outside of the monolith 1st 1. Come up with a module structure 2. Create some modules a. Dependency management! 3. Put stuff in the modules a. Analyse dependencies b. Break dependencies i. Works? Great! Move it! ii. Doesn’t work? Try again later
31. one feature outside of the monolith 1st 1. Come up with a module structure 2. Create some modules a. Dependency management! 3. Put stuff in the modules a. Analyse dependencies b. Break dependencies i. Works? Great! Move it! ii. Doesn’t work? Try again later 4. Rinse and Repeat! Forever!
32. 1st attempt
34. 10th attempt
36. 100th attempt
38. It takes time. Be patient.
39. one feature outside of the monolith 1st
40. one feature outside of the monolith 1st frameworks and APIs outside the monolith 2nd
41. one feature outside of the monolith 1st frameworks and APIs outside the monolith 2nd (almost) everything outside the monolith ulti mat e
42. 2015 2016 2017 LOC in repo LOC NOT in the monolith LOC in the monolith
43. Modularizing Feature development
44. “We can’t do xyz outside of the main module”
45. If new code is written as if it was in a module, it will be easier to modularize
46. Best practices
47. Best practices in practice Deprecate and remove legacy code
48. Best practices in practice Deprecate and remove legacy code Stop re-implementing the wheel
49. Best practices in practice Deprecate and remove legacy code Stop re-implementing the wheel Stop leaking implementation details
50. Best practices in practice Deprecate and remove legacy code Stop re-implementing the wheel Stop leaking implementation details Use dependency injection
51. Best practices in practice Deprecate and remove legacy code Stop re-implementing the wheel Stop leaking implementation details Use dependency injection Structure! Code organization! Consistency!
52. Best practices in practice Deprecate and remove legacy code Stop re-implementing the wheel Stop leaking implementation details Use dependency injection Structure! Code organization! Consistency! SOLID principles
53. SOLID Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle
54. SOLID S - Don’t do a lot of things in one class O - Design the API of the class so that it can be used and extended without being modified L - Don’t let implementations of the same interface behave differently I - Don’t design big interfaces D - Depend on abstractions, not on implementations
55. SOLID S - Don’t do a lot of things in one class O - Design the API of the class so that it can be used and extended without being modified L - Don’t let implementations of the same interface behave differently I - Don’t design big interfaces D - Depend on abstractions, not on implementations
56. So, does best practices work?
57. 2015 2016 2017 2018 LOC in repo LOC NOT in the monolith LOC in the monolith
58. It’s still painful
59. LOC in R.java LOC in repo LOC in the monolith
60. LOC in R.java LOC in repo LOC in the monolith 56 million
61. Android Gradle Plugin 3.3 android.enableSeparateRClassCompilation=true
62. What’s the lessons?
63. Patience. Focus. Just move, DO NOT TOUCH.
64. “It’s hard to see the forests for all the trees”
65. Modularization is a tool
66. Modularization is a chance to get to know your codebase
67. Modularization is a chance to tackle tech debt
68. “Single modules are easier to deal with; there are no complex dependency graphs to account for [...]” - Yelp
69. “Single modules appear to be easier to deal with; there are no complex dependency graphs to account for [...]” - Yelp (revised by Elin)
70. The complex dependencies are still there, they’re just hidden
71. Modularization How hard can it be?
72. Very
73. Software development How hard can it be?
74. Very
75. Very You can make it easy, you can make it hard
76. #OddlySatisfying
77. Thank you! Elin Nilsson @hejelinnilsson