"How to design your app and not be damned by maintenance team" from Anton Minashkin

Anton's topic will answer the questions how to tame your architecture, control complexity, continuously reduce technical debt and not go crazy. You will found out following tips, tricks and complaints.

1. How to design your app ...and not be damned by maintenance team by Anton Minashkin
2. What is Architecture? “Architecture is About Intent, not Frameworks” Bob Martin
3. The Big Aim
4. Problem
5. Popular Solutions • MVP • MVC • MVVM • MV* • No architecture
6. MV* Problems • Too high level • Not designed for Android • Solve only UI isolation problem
7. MV* Problems MVC (P/VM/ etc.) Business logic
8. Requirements • Maintainable • Testable • Flexible • Independent of DB/UI/Frameworks/Libs
9. Requirements: Maintainable • Documented • Simple on each level • Loosely coupled • Without technical dept • ...or at least technical dept should be clear enough
10. Requirements: Testable • Easy to prove that universe works • Fearless refactoring • Every component could be mocked
11. Requirements: Flexible • Possibility to add/remove feature without side effects on other features • If something looks like small change - it should be small change • Implementations could be changed without side effect • UI changes affects only UI (!!!)
12. Requirements: Independent of 3d party libs • Tools should be used as tools • Possibility to change any lib/framework without pain and in reasonable time • Any 3rd party solution should be easy to mock
13. Divide et impera • Keep the business rules not knowing anything at all about the outside world, • Single responsibility • Isolation on all levels
14. Mutable vs Immutable 1. UI 2. 3rd party libs/Tools 3. Business logic 4. Backend protocol
15. Divide et impera Presentation Layer MV*, UI Domain Layer Pure Java Data Layer Repository, Networking, Cache, etc. Use cases DAL
16. Presentation Layer • Should be in separated module • Should not contain any business logic • Should depend on Domain (IoT) • MV* and UI goes here
17. Domain Layer • You don’t need Android here • Pure Java only • Should not contain dependency on other modules
18. Data Layer • Network • Cache • DB
19. Android as an Infrastructure
20. Android as an Infrastructure • Build and initialize all other components • Provide dependencies • Connect Domain with Context and Lifecycle • Manage Android Components
21. Architecture as a Process
22. CI • NEVER provide builds manually • Run tests on every commit • Add all checks to CI
23. CI: Tools
24. Testing • Tests is also first class citizen • Tests as a part of documentation • In 2016 you will have no excuses not to write tests
25. Testing: Domain Layer • Unit tests with JUnit • Mockito (or any other mocking tool)
26. Testing: Presentation Layer 1. Espresso 2. UI Automator 3. RoboElectric
27. Testing: Data Layer • RoboElectric • JUnit
28. Roleplay
29. Delayed decision Time = Information
30. Occam's razor / Programming through the pain
31. Universe changes
32. TDD
33. Use metrics • Don't forget a meaning • Measure everything • It is not only about warnings • The Boy Scout Rule
34. Technical dept • Do not afraid of refactoring • Include refactoring to every iteration • Test it! • Measure it!
35. Documentation • If something is deprecated - @Deprecate it • JavaDoc your API • Tests is a part of Documentation
36. Think in Java Android Accept the rules of the game ...or Google will break your app
37. Summary • Application should be concentrated on Business Logic, not UI • Divide et impera • Architecture as a Process • In the next year everything will change
38. Read.me http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/ Robert C. Martin https://www.youtube.com/watch?v=BlkJzgjzL0c https://www.youtube.com/watch?v=vdasFFfXKOY