If you had to choose just one rule that you think is the most important rule for good software design, what would it be?
For further actions, you may consider blocking this person and/or reporting abuse
If you had to choose just one rule that you think is the most important rule for good software design, what would it be?
For further actions, you may consider blocking this person and/or reporting abuse
Tyra Clemente -
Chris Trag -
Long Bui -
Adrian Machado -
Top comments (12)
This is a hard one, but if I have to choose it would be : Seperation of Concerns. It would void spaghetti code effect, improve readability, navigability and hopefully testability. And these, I believe, are at the core of clean code/design.
Always leave the campsite cleaner than you found it.
When you pop in to fix a bug or plop in some code, take it as a chance to improve the code, add tests, etc.
I think ongoing habits matter more than rote architecture ideals.
Listen to the unit tests.
A unit test should be very easy to write in no more than 3 or 4 lines. If more, you probably have coupling but don't go overboard or your classes will lack cohesion!
Basically: a unit test should be easy to write on a couple of lines but be on the lookout to ensure that your class have meaning.
Be explicit.
I've seen too many times things abstracted to the point where things just get too generic and you have no idea what's happening.
Honestly, I'd rather see the "same" non-business critical code duplicated then have to dig down through 5 levels of inheritance why dynamically generated methods on a class (yes, I had to refactor this kind of monstrosity in the last year! 😂)
For example, if your business has a rule that blog posts shouldn't have more than 10000 words per article, then a class called
ArticleHasLessThan10000Wordswould be very explicit and easy to understand what it does.I find this happens when we focus on the business aspect of what we are trying to solution vs. the technical "how"
Less is More.
This can be applied to any aspect of software design. Reducing complexity in code makes it easier to understand; cutting out unnecessary features can make the program easier to use for customers, even removing useful features, and putting them in their own project can often improve the user experience for more advanced users who might only need one aspect of your product (While you can still provide a wrapped up version for those users who just want a monolith that gets every job done).
This principle can also be applied to many other aspects of life, from the way we think about material wealth to how much salt we put in our food.
People come first. The code you write should always ultimately serve the people who will use the product. If you can't think of how your work will help the end-user, take a step back and think about it.
Three rules: SRP, SRP, and more of SRP 😁
Can you explain it? If you can't explain it then don't do it.
Be aware of the drawbacks of what you choose, the benefits of what you didn't choose, and the meaning of all these in your specific project.
Write it like if you were the one who's going to read it in 10 years.