Where on the doll did software eng. evangelism hurt you?
First of all - I like programming discussions, over the years I've witnessed thousands of them
and they significantly helped me to gain knowledge and allowed me to gain various perspectives of real world software engineering.
Yet, I struggle to understand how we ended with such scenario
where fundamental things like SOLID (any many more!) have tens of various interpretations and nobody cares.
Like, if you asked 50 people about SOLID, then you'd hear like 10 or 20 various interpretations.
You can see SOLID discussions on the internet forums over and over again, pretty much on a regular basis.
The even worse thing is that some of those "fruits of software eng. evangelism"
are becoming so "good", "important", "obvious" that if you aren't using them, then there's something wrong with you.
It is especially tricky when people have different interpretations of things, so you'd need to ask people
"How do you understand X" in order to be able to answer "Are you using X?".
The craziest example: Are you using TDD or you do not test your software?
<sarcasm>Dear reader, did you know that tests do not exist without TDD? :rofl:</sarcasm>
Some principles of SOLID like "Interface Segregation Principle" are rarely discussed,
but other like "Single Responsibility Principle" are constantly being discussed, what does it mean?
I think, it suggests a failure of an attempt to formalize given concept.
The fact that principles in software engineering are very arbitrary and that we lack of any formal proof behind them doesn't help too.
I couldn't understand why would anyone use a "reason" word in "every class should have only one reason to change"
Like you can have many reasons to change SOLID™ code, what the hell?
Then I learned that it is about more "higher level" things, you know, like functional requirements and stuff
But then, why is it mixing abstraction levels without additional description? Aren't those principles usually sold as a very close to code level?
It makes no sense and is confusing, and apparently other ppl had similar feeling (quoting UncleBob's blog)
Some folks have wondered whether a bug-fix qualifies as a reason to change.
Others have wondered whether refactorings are reasons to change.
These questions can be answered by pointing out the coupling between the term "reason to change" and "responsibility"
Later I found that UncleBob revisited this one, and it isn't about "reasons" anymore, but people/actors!
"A module should be responsible to one, and only one, actor."
I feel like this one is better, but holy fuck, why it cannot be straightforward in order to try to minimize amount of various interpretations?
Minimize because I don't think we can reach just 1 interpretation.
I'd rewrite it as: Try to avoid implementing different concepts in the same place (e.g. class/function/etc.). Consider taking it as dependency
But still, that's yet another interpretation - who gets it right or has the best wording? no idea
For example:
When writing a function that's sending email basing on database's input, then
avoid implementing database access code and email sending code in this function.
Database access code and email sending code shouldn't be together, too.
PS: Let's try to avoid gluing ourselves too much to the specific paradigm.
Is software eng. evangelism failing people?
I think it kinda does.
A lot of principles are pushed onto people, especially beginners and are sold as a fundamentals, yet sometimes they are not well written and require years of experience to understand.
When principles are not well written you need to spend a lot of time wondering whether you are an idiot that doesn't get it, or that there's a lot of bullshitting around it.
If you experienced similar stuff and you're tired of this then I recommend going to lower levels of tech stack, closer to FW/HW.
For some *reasons* there is way, way less things like this.