Member-only story
What Are the Fundamentals of Good Software Design?
Don’t fall into junior developer pitfalls or overcomplicate things
In this article, I want to elaborate on the broad concepts of good software design rather than the specifics that may differ a little from language to language.
When is code good and when is it bad? It’s a subjective and controversial topic. There are a lot of language- or framework-specific rules and guidelines, but I have a strong belief that good code or good design is not only or always tied to them. Often, they make code complex, scattered, and over-structured. Therefore, I believe that good design is subject to its use case.
Luckily, I think there are still some ways to determine if the software can be considered “good” or “bad” for its use case.
Good Design Is Simple
Often, I come across code that is perfectly structured with all the bells and whistles, set up with proper interfaces, and it adopts specific code patterns and code style tools that do not return a single error or warning. But still, I think it sucks.
Every time something is written, it should be proportional. A lot of developers adopt patterns just for the sake of patterns. They’re almost yelling, “Look how good I am at adopting this pattern I just read about” instead of really understanding why they chose a specific pattern.
Good design is often simple. By that, I mean proportional to the size of the solution they provide. If you provide a simple feature to the application that is only used once, should you be using all kinds of fancy stuff? Think about if your code complexity is proportional to the solution you are providing. Is your feature going to be the backbone of your application or the base of an extension or inheritance in your application? You better have it well structured. Is it just a solution to a small problem in your application? It better be as simple as it can be.
We Tend to Overcomplicate Our Features
When talking to the Project Owner of our application, we retrieve requirements. After first drawing out our ideas for the implementation, we often overcomplicate the initial design of our approach…
