Though we are talking about software design everyday. But which criterion we rely on to evaluate whether it's good or bad design? Sometimes, I felt ridiculous because some people always said that they have a good design skills but when I asked them what is a good design. They couldn't answer. When we talk about something good we need evidences. If we develop a good product, we have to have an ability to tell our customers know how good it is. Making a good product is not enough. Even we think we made the good one but how you convince yourself.
Honesty and Straightness make the excellent engineers. Because only if we are honest with ourselves we can look straight to our weakness and the bad things in our design. If we try to deny it, ignore it we will never improve. A brave person who is always like that. Time has changed everything. We need to keep learning and improving everyday.
In fact, there are many dimensions in software design. However, we have some standard criterion.
Loose Coupling. This is the very first criteria I appreciate in software design. In order to evolve, we have to make the loose connections among parts of software. We break software into smaller parts and make the connections as less as possible. Time and Change ares the factors which effect our software. We make sure that if we make changes, we just make enough changes. Changes are always the cause of bugs and risks.
Extensibility. Our software need to evolve time by time. We know for sure that we will add more features in future. We do that without effecting other pieces of code. That's what Open/Closed principle talks about.
Reusability. In order to avoid bugs by duplicated code and making it hard to control, we should write functionalities somehow we can reuse them. It also save our time and money.
Minimal complexity and Ease of maintenance. We design or write code somehow the code can speak itself. We are not writing code for ourselves to read but for anyone who will join the team and catch up fast with development. Developer should marry with design patterns, best practices and SOLID principles. If I can let the other team members get easy to understand my code, that would be my success. I'm not talking about the syntaxes. I'm talking about design, how to divide and arrange our code.