The Immense Benefits Of Not Thinking In Screens

Video: https://badootech.badoo.com/the-immense-benefits-of-not-thinking-in-screens-6c311e3344a0

Abstract:

Maintaining a large project and not going insane — in practice:

– Causes of everyday development pain, frustration and slowdown less frequently talked about

– Breaking down the complexity of screens instead of a classical layering approach

– Keeping code easy-to-understand, decoupled and maintainable even in highly complex projects

– A plug-and-play component architecture where individual pieces don’t require a deep understanding or careful wiring and can be reused in a few minutes

We now have over half a billion users across a growing portfolio of apps, including Badoo, Bumble, Chappy and Lumen.

A year ago we set out on a journey to unify and scale up our approaches to reduce component reuse and maintenance times by an order of magnitude. We reached for maximal reusability and minimal coupling between individual components.
Many of the lessons we learned in the process have immense practical benefits for projects of all sizes.

Transcript

1. @ZsoltKocsi The Immense Benefits Of Not Thinking In Screens
2. Hello!
3. JOE TOOK THIS SILVER BULLET SOFTWARE ENGINEERS HATE HIM! WHAT HAPPENED NEXT SHOCKED EVERYONE
4. @ZsoltKocsi Android engineer @ Badoo by MagicLab
7. REC 7
8. III. PRACTICAL IMPLEMENTATIONS I. PROBLEM DEFINITION II. IDEAS
9. I. PROBLEM DEFINITION
12. The 5 stages of grief software engineering 1. Denial 2. Anger 3. Bargaining 4. Depression 5. Acceptance 12
13. The 5 stages of grief software engineering 1. Denial 2. Anger 3. Bargaining 4. Depression 5. Acceptance 13
14. FOCUS SHIFT? 14
15. Important-ish 1. libraries 2. frameworks 3. MVWhatever 4. the newest fad! 15
19. SYMPTOM: COUPLED MESS
23. Reuse time: insane method: lots of pain 23
24. UNDERLYING ISSUE: COUPLING
29. COUPLING
30. COUPLING ~ COMPLEXITY GETTING OUT OF HAND
31. COMPLEXITY GETTING OUT OF HAND ~ THINKING IN SCREENS
32. BAD HABIT: thinking in screens
34. This is fine 34
36. Data Domain Pres. 36
39. III. PRACTICAL IMPLEMENTATIONS I. PROBLEM DEFINITION II. IDEAS
40. II. IDEAS
41. classes — ??? — project 41
45. classes — ??? — project 45
46. classes — MODULES — project 46
47. MODULES: Right boundary? 47
48. WHOLE SCREEN IS A MODULE 1. can easily get out of hand 2. reuse sub-screen? 48
49. SCREEN CONSISTS OF MANY MODULES 1. To reduce complexity 2. To reuse parts of the screen 49
50. SUGGESTIONS FOR BETTER MODULES
51. SUGGESTIONS FOR BETTER MODULES 1. black boxes 51
52. 1. black boxes 52
53. 1. black boxes 53
54. 1. black boxes 54 Entrance Hidden details
55. 1. black boxes 55
56. SUGGESTIONS FOR BETTER MODULES 1. black boxes 56
57. SUGGESTIONS FOR BETTER MODULES 1. black boxes 2. require no deep understanding to use 57
58. 2. require no deep understanding to use TIP #1: self-documenting high-level interface 58
59. interface ExampleComponent { interface Dependency { fun userDataSource(): UserDataSource fun inputSource(): ObservableSource<Input> fun outputConsumer(): Consumer<Output> } sealed class Input { object DoSomething : Input() } sealed class Output { data class SomethingHappened(val entity: MainEntity) : Output() } data class MainEntity( val text: String ) } 59
60. interface ExampleComponent { interface Dependency { fun userDataSource(): UserDataSource fun inputSource(): ObservableSource<Input> fun outputConsumer(): Consumer<Output> } sealed class Input { object DoSomething : Input() } sealed class Output { data class SomethingHappened(val entity: MainEntity) : Output() } data class MainEntity( val text: String ) } 60
61. interface ExampleComponent { interface Dependency { fun userDataSource(): UserDataSource fun inputSource(): ObservableSource<Input> fun outputConsumer(): Consumer<Output> } sealed class Input { object DoSomething : Input() } sealed class Output { data class SomethingHappened(val entity: MainEntity) : Output() } data class MainEntity( val text: String ) } 61
62. interface ExampleComponent { interface Dependency { fun userDataSource(): UserDataSource fun inputSource(): ObservableSource<Input> fun outputConsumer(): Consumer<Output> } sealed class Input { object DoSomething : Input() } sealed class Output { data class SomethingHappened(val entity: MainEntity) : Output() } data class MainEntity( val text: String ) } 62
63. interface ExampleComponent { interface Dependency { fun userDataSource(): UserDataSource fun inputSource(): ObservableSource<Input> fun outputConsumer(): Consumer<Output> } sealed class Input { object DoSomething : Input() } sealed class Output { data class SomethingHappened(val entity: MainEntity) : Output() } data class MainEntity( val text: String ) } 63
64. 2. require no deep understanding to use TIP #1: self-documenting high level interface 64
65. 2. require no deep understanding to use TIP #1: self-documenting high level interface TIP #2: automatic setup 65
66. interface ExampleComponent { interface Dependency { fun userDataSource(): UserDataSource fun inputSource(): ObservableSource<Input> fun outputConsumer(): Consumer<Output> } sealed class Input { object DoSomething : Input() } sealed class Output { data class SomethingHappened(val entity: MainEntity) : Output() } data class MainEntity( val text: String ) } 66
67. interface ExampleComponent { interface Dependency { fun userDataSource(): UserDataSource fun inputSource(): ObservableSource<Input> fun outputConsumer(): Consumer<Output> } sealed class Input { object DoSomething : Input() } sealed class Output { data class SomethingHappened(val entity: MainEntity) : Output() } data class MainEntity( val text: String ) } 67
68. interface ExampleComponent { interface Dependency { fun userDataSource(): UserDataSource fun inputSource(): ObservableSource<Input> fun outputConsumer(): Consumer<Output> } sealed class Input { object DoSomething : Input() } sealed class Output { data class SomethingHappened(val entity: MainEntity) : Output() } data class MainEntity( val text: String ) } 68
69. 2. require no deep understanding to use TIP #1: self-documenting high level interface TIP #2: automatic setup time to reuse: weeks —> minutes 69
70. SUGGESTIONS FOR BETTER MODULES 1. black boxes 2. require no deep understanding to use 70
71. SUGGESTIONS FOR BETTER MODULES 1. black boxes 2. require no deep understanding to use 3. universal approach 71
72. 3. universal approach Reflexes: • Different approaches per level of hierarchy • View, Fragment, Activity, ViewPager, ??? 72
73. 3. universal approach Better: • Abstract away from screen! 73
74. SUGGESTIONS FOR BETTER MODULES 1. black boxes 2. require no deep understanding to use 3. universal approach 74
75. SUGGESTIONS FOR BETTER MODULES 1. black boxes 2. require no deep understanding to use 3. universal approach 4. constraints! 75
76. 4. constraints! freedom of choice <—> unification 76
77. 4. constraints! freedom of choice <—> unification 77
78. SUGGESTIONS FOR BETTER MODULES 1. black boxes 2. require no deep understanding to use 3. universal approach 4. constraints! 78
79. SUGGESTIONS FOR BETTER MODULES 1. black boxes 2. require no deep understanding to use 3. universal approach 4. constraints! 5. structure 79
80. FLAT HIERARCHY
83. DEEP HIERARCHY
85. SUGGESTIONS FOR BETTER MODULES 1. black boxes 2. require no deep understanding to use 3. universal approach 4. constraints! 5. structure 85
86. SUGGESTIONS FOR BETTER MODULES 1. black boxes 2. require no deep understanding to use 3. universal approach 4. constraints! 5. structure 6. limit visibility 86
91. 91 X X X
94. THOSE IMMENSE BENEFITS!
95. BENEFITS 1. Similarity++ 2. Complexity-- 3. Coupling-- 95
96. BENEFITS 1. Similarity++ 2. Complexity-- 3. Coupling-- 4. Proper scoping (DI) 96
99. BENEFITS 1. Similarity++ 2. Complexity-- 3. Coupling-- 4. Proper scoping (DI) 99
100. BENEFITS 1. Similarity++ 2. Complexity-- 3. Coupling-- 4. Proper scoping (DI) 5. Testing in isolation 100
101. 101 Instrumentation test screen App
102. BENEFITS 1. Similarity++ 2. Complexity-- 3. Coupling-- 4. Proper scoping (DI) 5. Testing in isolation 102
103. III. PRACTICAL IMPLEMENTATIONS I. PROBLEM DEFINITION II. IDEAS
104. III. PRACTICAL IMPLEMENTATION
105. uber/RIBs 105
106. uber/RIBs We absolutely loved: • Tree-structure with routing
 • Screen-agnostic
 • Nested scopes 106
107. uber/RIBs We missed: • Tree state not restored
 • No routing back stack 107
108. Addressed those issues + Tons of other cool things! + (hopefully) better tutorials Badoo/RIBs https://github.com/badoo/RIBs Diff: 108
109. Badoo/RIBs https://github.com/badoo/RIBs Diff: 109
110. Badoo/RIBs https://github.com/badoo/RIBs Give it a go! 110
111. SUMMARY
112. KEY IDEAS TODAY 1. Focus on the level between classes and the whole project 2. Create strong boundaries to avoid coupling 3. Abstract away from screens 4. Keep things similar 5. Keep things simple
113. https://badootech.badoo.com