There are several reason for adding architecture into your app. Developers spend 10 times as much time reading code versus writing it. Architecture helps us avoid bugs, isolate complex code, and speeds up development allowing multiple developers to work independently of each other while working in dependent areas. Some good arguments against using architecture include: using architecture because that's just what we do; sometimes speed is more important than perfect architecture. There is a spectrum of architecture that can be implemented, with some pieces providing a lot of value, at little cost. Some misconceptions about using architecture include the idea of not needing architecture, because we need to move fast: there is always a trade off in speed vs. technical debt. And YAGNI (You Aren't Gonna Need It). In large applications, you are going to need some of this, and keeping to simple, consistent patterns keeps your code readable and maintainable.
- [Instructor] 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 of 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'll 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.
- Moving pieces of architecture
- Designing an MVA app
- Walking through a demo application
- Converting to MVP
- Moving non-view logic to a presenter
- Breaking logic into layers
- Using entities
- Setting up dependency injection
- Implementing the coordination pattern
- Adding data binding with RxSwift