For me, good design means that when I make a change, it’s as if the entire program was crafted in anticipation of it. I can solve a task with just a few choice function calls that slot in perfectly, leaving not the slightest ripple on the placid surface of the code.
That sounds pretty, but it’s not exactly actionable. “Just write your code so that changes don’t disturb its placid surface.” Right.
Let me break that down a bit. The first key piece is that architecture is about change. Someone has to be modifying the codebase. If no one is touching the code — whether because it’s perfect and complete or so wretched no one will sully their text editor with it — its design is irrelevant. The measure of a design is how easily it accommodates changes. With no changes, it’s a runner who never leaves the starting line.
This. There are few things that I feel like are as satisfying as being like "Oh crap, I need to make sure it can handle ABC" or "I need to change it for this new thing" and realizing you wrote it such that sure, it does need to change somewhere, but it has that capability for change without things getting messy. The opposite of having to add more and more logic to handle cases.
Key goal of software architecture: minimize the amount of knowledge you need to have in-cranium before you can make progress.
Get problem -> Learn Code -> Code Solution -> Clean up
Change to one piece of code doesn’t necessitate a change to another. We obviously need to change something, but the less coupling we have, the less that change ripples throughout the rest of the game.
Good architecture makes a huge difference in productivity. It’s hard to overstate how profound an effect it can have.
Good architecture takes real effort and discipline. Every time you make a change or implement a feature, you have to work hard to integrate it gracefully into the rest of the program. You have to take great care to both organize the code well and keep it organized throughout the thousands of little changes that make up a development cycle.
You have to think about which parts of the program should be decoupled and introduce abstractions at those points.
Writing well-architected code takes careful thought, and that translates to time. Maintaining a good architecture over the life of a project takes a lot of effort. You have to treat your codebase like a good camper does their campsite: always try to leave it a little better than you found it.
Design requires a lot of experimentation and exploration. Especially early on, it’s common to write code that you know you’ll throw away.
If there is any method that eases these constraints, it’s simplicity. In my code today, I try very hard to write the cleanest, most direct solution to the problem. The kind of code where after you read it, you understand exactly what it does and can’t imagine any other possible solution.
I like this a lot. "Accommodation to changes" accounts for readability, organization, testing, and a lot of other things bundled in.
Coding only for the problem at hand right now: Bad.
Coding for every possible future need: Bad.
Coding to solve current problems while being accommodating towards future modifications: Good.
There's a really great chapter about this in "Game Programming Patterns" by Robert Nystrom:
Be sure to read the whole thing!
This. There are few things that I feel like are as satisfying as being like "Oh crap, I need to make sure it can handle ABC" or "I need to change it for this new thing" and realizing you wrote it such that sure, it does need to change somewhere, but it has that capability for change without things getting messy. The opposite of having to add more and more logic to handle cases.
A few points taken from Robert Nystrom are:
I like this a lot. "Accommodation to changes" accounts for readability, organization, testing, and a lot of other things bundled in.
Coding only for the problem at hand right now: Bad.
Coding for every possible future need: Bad.
Coding to solve current problems while being accommodating towards future modifications: Good.
I have seen this scenario a few times and it obviously delays the whole project because requirements keep changing and so does the code.