The Importance of Application Architecture

One key way I am aiming to make this course different from many beginner to intermediate level courses, is that we will be paying much more attention to architectural concepts right from the beginning. In the beginning, this can make things harder because we aren’t doing things in the most simple way possible, and the reasons why we are doing things a certain way might not be immediately apparent without taking some time to learn additional concepts.

To give some context here, we are primarily going to be focusing on these three architectural concepts throughout this module (and then using them throughout the course):

• SOLID programming principles — an acronym representing five best practices for building software with Object Oriented Programming
• Smart and dumb components — a way to distinguish between different types of components and the responsibilities they have
• Folder structure — how to organise the files and folders in our application in a more maintainable/scalable way

You don’t actually need to care about any of these things to build an application, so why should we care about them at all? In a way, it’s similar to the argument for using state management libraries. Or using declarative code. For basic applications, not considering these best practices probably isn’t going to cause any trouble. As an application becomes bigger, not considering these best practices can lead to hard to maintain and buggy code. The line of where it starts to matter is not clear, and I think it is a good idea to always consider these things.

I say consider, because it is important to learn these concepts and how they might be beneficial, but they might not always be required. I would argue the smart and dumb component architecture and folder structure is something we should just always do by default, but for the SOLID programming principles we also want to be careful not to over engineer things. It is good to understand the concepts behind SOLID programming, but in some cases we might not always need the optimisations that it advocates for.

A key different between a beginner and an advanced developer, in my opinion, is their ability to understand architectural concerns like this and when best to apply them.

In general, the benefits of adhering to the concepts we will discuss in this module (where appropriate are):

• Code that is maintainable and scales well
• Code that has less bugs
• Code that is easy to navigate
• Code that is extendable
• Code that reduces duplicated efforts (i.e. doing the same thing over and over again)
• Code that is modular and reuseable
• Code that makes you like coding (not pull your hair out)

I strongly believe one of the biggest factors in determining software quality is developer experience — to put it simply, happy developers are going to write better code. All of these concepts we are talking about might seem like they are making writing code harder. But really they are dealing with complexities that exist in software development regardless — if they are ignored they are just going to cause you pain in other ways. Learning these concepts is about making it easier to develop and maintain applications — to master the chaos of software development. There is no more miserable experience in software development than ending up with a poorly designed codebase that results in fragile code that constantly causes bugs.

In the rest of this module, we will dedicate one lesson to each of the three points I mentioned.