Solid Design Principles: The Guide to Becoming Better Developers(adevait.com)
adevait.com
Solid Design Principles: The Guide to Becoming Better Developers
https://adevait.com/software/solid-design-principles-the-guide-to-becoming-better-developers
1 comments
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.
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.
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".
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".
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.