Solid Design Principles: The Guide to Becoming Better Developers | Hacker News Reader

Solid Design Principles: The Guide to Becoming Better Developers

adevait.com

27 pointstrajchevska5 comments

I've now been a professional software developer for about 10 years and have come to the exact opposite conclusion of this article. I've come to find that these types of principals lead to the opposite of readable code for me. Principals like solid lead to overly abstract code that becomes very hard to follow. I prefer code to be as linear, obvious and unsurprising as it can be and the amount of useless abstractions that get bolted on to make code SOLID do the opposite of that. Some principals I have found useful:

YAGNI KISS DRY

In that order. First, try not to do the thing. Second, if you have to, make it as simple and straight forward as possible. Third, don't repeat yourself but observe one and two first.

I'm in the same position, I think. I used to be a SOLIDhead but I find the adherence to SOLID increasingly off-putting.

Primarily code should do the thing simply and obviously. The best attribute of any code, in my view, is that it's easy to delete when the requirements change or you have to pivot. There are some fundamentals of good design when writing code (prefer immutability, minimise shared state) which help to make code easier to reason about but overeager application of SOLID or design patterns tends to result in the wrong abstractions that grow out of control when they need to be worked around because they don't fit.

If you write the code with YAGNI and KISS in mind any applicable pattern tends to become obvious over time.

I think SOLID is appropriate for the public interface parts of your code but the internals should strive for YAGNI/KISS.

So the vast majority of your codebase should aim to minimize lines of code and abstraction. Of course there are exceptions - sometimes you really do need to encapsulate complex sub-systems with abstractions but you should have a clear justification.

This is the conclusion I have reached, well put.

I think the DRY in popular mind-share (where it seems largely syntactic) is substantially less valuable than the original formulation, which spoke of "pieces of knowledge".

There are (at least) two ways the two differ:

First, stating the same thing in many different forms is not DRY, even if it doesn't look like repetition. If the piece of knowledge is "there is a button there", then saying so in HTML and JS and CSS isn't DRY.

Second, something might look like repetition but in fact be representing different "pieces of knowledge" in each place. Unifying them is not "more DRY".

Reply on news.ycombinator.com