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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A few points taken from Robert Nystrom are: