Good architecture makes your life easier, it doesn’t make your code more functional.

Perhaps this is why it’s a bit hard to explain why good architecture practices matter in a big project. Because in truth, it’s more about avoiding bad architecture practices.

In most cases, this is not a nitpick. If your code base struggles to scale then scaling could feel like walking on eggshells, cost you a lot of precious production time, and could even lead you to be involved, ironically enough, in architectural concerns throughout the development of your application.

It takes more effort to implement this complicated scalable practices though, right?

It’s a big misconception that good, scalable architecture takes more time or effort to implement necessarily than whatever is considered the opposite.

Have I already mentioned it’s about doing less of the bad stuff than doing more of the good stuff? Because that was geniune.

I promise you won’t need to implement 15 design patterns to build scalable features. Sticking to a basic set of practices and rules is enough. I find that when I’m writing something new now, I naturally follow these rules, and they’re enough to scale, but also enough to not scale if I didn’t want to.

With that being said…

This is not a design pattern book

I’m thinking of including a chapter about design patterns, but it’s really non-essential.

Here’s the thing: I’ve seen very well put together implementation of design patterns before in projects that were still somehow a pain to debug and work with.

There’s this notion that software architecture is about design patterns. But I’d argue that implementing the command pattern won’t suddenly give you an effective workflow for your card game, and it certainly won’t make a codebase with 200 scripts referencing each other more manageable.

In that case, what makes good architecture?

That’s a very hard question to answer. It’s good to note that any answer to this question is subjective.

But these are some markers based on what I think the smarter developers who I had the luck to work with and learn from throughout my career would agree on:

Features are decoupled and locked for modification

When a feature knows and references another feature, it can’t exist without it. It’s like they’re a married couple!

Good architecture in that sense is when your feature is locked for modification. What does that mean? Your goal when building many features is to finish implementing a feature and be done with it unless you need to modify its behaviour.
This is so that when you’re done with the implementation, you test that it works, and that’s it. You don’t modify the feature anymore since it works. You can focus your attention on other features without worrying about this one feature breaking. Doesn’t that sound far more manageable when you have 300 features to work on?

So for example: say your enemy script references your save system. If all of a sudden you’re now saving to the server instead of saving locally, and that requires changes to the enemy class for some reason, then your enemy class is not locked for modification.

Features have clear relationships

Perhaps the simplest way to explain this is when you have, say a feature that affects all the enemies in the scene. This feature will need references to all of their active instances.

Now here’s a new requirement: another feature that needs access to all the enemy references in the scene. Now you somehow need to grab all of their references one more time.

Imagine this: all of your enemies had a class that manages their references and lifecycle from the get go. This is why I mentioned earlier that bad scalability practices result in architectural concerns well into your development cycle. Clear relationships should result in workflows where you’re not spending a lot of time thinking of which feature connects with what.

Easy to work with/effective workflow

An aspect that’s often underappreciated is workflow. If you’re building a card game with a 1000 cards, you certainly don’t want each card to be its own class. A more effective workflow would be to break down the card effects into building blocks, and combine them through data representation.

But even small stuff matter in the long-term. For example, if the feature setup requires me to view a documentation somewhere every time I build a new level, then that’s an aspect that can certainly be improved upon.

What you’ll learn through this book

Given the context in this chapter, I hope it’s obvious why the second part of this book is all about decoupling. It introduces some techniques to build decoupled features to prepare you for more big-picture topics. The rest of the book is all about building relationships between your systems, and customizing your workflow.