Why architecture?

Keyboard Shortcuts

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 differenttypes of architecture available to us,let's first talk about some of the argumentsfor 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 ratioin his book, Clean Code.He says, indeed, the ratio of time spent readingversus writing is well over 10 to one.

We are constantly reading old codeas part of the effort to write new code.With even the most basic architectural elementsof separating our layers, we gain this benefitof simplification.Because pieces are broken intotheir single responsibilities, we also can avoid bugsand isolate our complex or frequently changingpieces of code into their own separate areas.This makes it so that developers can treat theseas black boxes that are simple to usewith their proper APIs.As your app and team grows and allows developersto specialize in areas they enjoy or feel comfortable in,such as UI concerns, or perhaps there's a developerwho loves the database or the network endpoints.

Now, let's talk about some reasons for not usingarchitecture 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 toeach piece of architecture, and they should be weighedwith time concerns, code quality and maintainability.They also should be thought of in terms ofhow easy to consume and reproduce consistently,as teams change over the years.There's also a trade-off between moving fastand gaining technical debt.

Your architecture ultimately needs to fitwithin your team's comfort levels within these two concepts.Fortunately, the architectures we will covercan be implemented in pieces,and there's a spectrum of effort with payoffsalong the way, as we progress along this spectrum.Now there are some deceptions in reasonsnot to use the architecture.One of them I've heard is sacrificing all architecturebecause 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 implementedwith 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 benefitsof using architecture within your application.Another argument against these architecturesis YAGNI, meaning you aren't going to need it.I've heard people say that this is the conceptthat 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 neededbefore 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 conceptsas you weigh in how much of the architectural spectrumyou want to implement, but with a lot of this,you are going to need it.

You'll want an easy to read code baseand you will want to develop fastwhile some of the other underlying portionsof your code aren't finished,such as endpoints that may need to be fakeduntil 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 upsome of the methods that will return the piecesthat 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.

Resume Transcript Auto-Scroll

Author

Released

6/27/2017

Developers need to know how to minimize app complexity and maximize scalability. Good architectural planning—founded on established design patterns—is the key to solid code. This course provides an overview of the different architectural models and design patterns used to simplify enterprise applications. Learn how to audit an app and transition from MVC to a layered architecture, using models such as MVP, MVVM, VIPER, and MVA (minimum viable architecture). Instructor Jon Bott introduces the dependency injection pattern (for decoupling layers), the coordinator pattern (for managing application flow), and data binding with RxSwift.