Join Jon Bott for an in-depth discussion in this video Why architecture?, part of Android App Development: Design Patterns for Mobile Architecture.
- [Narrator] Before we go into the different types of architecture available to us, let's first talk about some of the arguments for and against architecture. First, it simplifies the code any one class contains and breaks them into single responsibilities. This is for both writing the code, but more importantly or impactfully, it simplifies the reading process. Bob Martin has written about a 10 to one reading ratio in his book, Clean Code. He says, "Indeed, the ratio of time spent "reading versus writing is well over 10 to one.
"We are constantly reading old code "as part of the effort to write new code." With even the most basic architectural elements of separating our layers, we gain this benefit of simplification. Because pieces are broken into their single responsibilities, we also can avoid bugs and isolate our complex or frequently changing pieces of code into their own separate areas. This makes it so that developers can treat these as black boxes that are simple to use with their proper APIs. As your app and team grows and allows developers to specialize in areas they enjoy or feel comfortable in such as UI concerns, or perhaps there's a developer who loves the database or the network endpoints.
Now, let's talk about some reasons for not using architecture within our apps. Seeing an over-architected solution is not that uncommon. I'm not a fan of architecture for architecture's sake. I think there are costs and benefits to each piece of architecture, and they should be weighed with time concerns, code quality, and maintainability. They also should be thought of in terms of how easy to consume and reproduce consistently as teams change over the years. There's also a trade-off between moving fast and gaining technical debt.
Your architecture ultimately needs to fit within your team's comfort levels within these two concepts. Fortunately, the architectures we will cover can be implemented in pieces, and there's a spectrum of effort with payoffs along the way as we progress along this spectrum. Now, there are some deceptions in reasons not to use the architecture. One of them I've heard is sacrificing all architecture because of the need to meet a deadline. This doesn't make things quicker. Some of these architectural pieces such as separation of your layers are so quick and simple, they can be implemented with a couple clicks of the mouse, and you gain huge benefits in readability, testability, and bug fixes.
With a couple of seconds of effort, you gain a huge piece of the benefits of using architecture within your application. Another argument against these architectures is YAGNI, meaning you aren't going to need it. I've heard people say that this is the concept that most of the stuff we write, we don't need, and that we should focus on the minimum viable product and wait for things to actually be needed before we implement them. YAGNI is a lot more about features and not so much about architecture. Don't get me wrong. You can apply these concepts as you weigh in how much of the architectural spectrum you want to implement.
But with a lot of this, you are going to need it. You will want an easy-to-read code base and you will want to develop fast while some of the other underlying portions of your code aren't finished such as endpoints that may need to be faked until they're implemented by another team. Or perhaps, you're waiting on other team members' tasks. You can sit and wait, or you can mock up some of the methods that will return the pieces that they eventually will deliver. With using the simplest pieces of the architecture, doing these type of activities are easy.
You are going to need it.
- Common architectures
- Minimum viable architecture (MVA)
- Converting to MVP
- Expanding layers
- Working with entities
- Dependency and interface injection
- Implementing the coordination pattern
- Adding binding with RxJava