Why use a known architecture in your app?

I believe architecture is vital to a good app. I sometimes compare the “art” of writing good architecture (or code) as the same as writing a good book.

You need to create a storyline, characters and a “plot” and in the end introduce them to each other so the final product will play out as we planned. Together with this you have to lay out a set of rules for the developer to follow in this particular book (App) because in programming you are never really done.

We as programmers are solving requirements for our clients and to do so we need to implement a system that makes it easy (not only for you) to continue to work on and at the same time be capable of handling the unforeseen future that you yet do not know.

Apps tend to get big. You need to write a lot of code and often you are many people working on the same project.

To combat this we can introduce the concept of “architecture”.

When applying code architecture you structure your codebase into a set of rules that marks your boundaries that contains modules and their relations between them.

In House of Code we have worked with several different architectures over the years and we are still learning. I don’t think you can ever set a checkmark and say that you totally nailed it.

Some of them include

• MVC
• MVVM
• VIPER
• Clean Architecture
• VIRP (homemade, basically a scaled down version of VIPER — don’t do it)

At the moment we explore VIPER (on iOS) and Clean Architecture (on Android) into more depth. We have used them in several projects. They are kind of massive but we also see great advantages.

You need to explore the ones that fits your project. There is plenty of comparisons on medium between the different architectures but the point here is why you should use one. We actually also did a home-rolled one but that turned out to be a mistake.

Top reasons why to use a known and documented architecture:

Team

• It is easier for multiple people to work on the same project as you agreed on a set of rules (and boundaries)
• Brining in new people on the project will go smoother because if they not already know about your architecture, then they can quickly learn by online tutorials
• It’s faster to understand and follow the flow. — you know where to look

Quality

• Code Review is a lot faster because you can concentrate on the logic and not worrying about responsibility as much
• Finding bugs can be easier because responsibility is clear — is the bug UI related, then you look at the UI layer
• Each code component is smaller — resulting in fewer bugs, because the developer only have to focus on smaller pieces of code at the same time
• Integrating tests is easy to do at any point. — because concerns is separated and mocking data is easy when using contracts between layers

Happiness

• When working on projects where the code “just flows” (or is nicely structured) you get happy developers — no body wants to walk into a messy house (or codebase)
• And because the developers agreed on an architecture to use, they are more motivated
• Motivated developers produce better code and are more creative

What we learned is that working with architecture is fun and challenging and that you grow with it — architecture can bring in some overhead but it definitely lifted our overall quality in every aspect.

Feel free to give me your thoughts.