
SOLID principles and how I was breaking them - mdziubek
https://codersbible.com/solid-principles-and-how-i-was-breaking-them-as-junior-developer/
======
metanonsense
One thing that I don't fully agree with is the treatment of Dependency
Inversion. As I see it, the Dependency Inversion Principle (DIP) and
Dependency Injection (DI) are quite different things living in different
dimensions. While DI, as he describes, might be a good candidate to implement
DIP, it is IMO by no means an example of DIP (unless I get the reasoning
wrong). In my understanding, DI is all about keeping objects that interact
with each other on the same layer of abstraction in order to avoid a semantic
impedance mismatch. The eponymous "inversion" part is about how we get objects
from different domains into the same abstraction layer: by defining an
interface in the language of our own module and implementing this interface in
the other module (or somewhere between).

Aside from that, I really like the idea of teaching abstract stuff with
examples and counterexamples.

------
Cube189
Never been in a project that took all those rules into consideration. Usually,
when pointing out the issue, it was me who was supposed to defend my point as
opposed to the person who wrote the code (or my comments got ignored
altogether).

~~~
all-out-of-hope
Oh wow, I find this extremely relatable, I was starting to think I was the
only one. I have the exact same experience, in fact, it's basically the only
thing I've experienced so far in my career. I remember so few times (while at
any job) where my opinion/experience/knowledge/ideas/code review/etc was ever
given any weight. On the other hand, helping people out online or wherever,
has always been a pretty positive experience for both of us and I've enjoyed
it.

> it was me who was supposed to defend my point

Professionally, on the other hand, it feels like I'm screaming into the void,
or sometimes at a brick wall. It's deeply frustrating, it's basically got to
the point where I just stop trying to change anything for the better, agreeing
to whatever inane changes they want to the code (even when I can see the clear
disadvantages that will hurt them more than me but they want it anyway), never
bothering to disagree with anyone more senior, basically being a yes man for
code. I've occasionally been able to work on something brand new, where I have
a little more control over the quality.

> opposed to the person who wrote the code

Getting someone to change code they "own" always seems to be impossible too,
no matter how tactfully you approach it, no matter how much evidence you
present that indicates a design flaw, no matter how well you explain why an
alternative is better, it's just so pointless.

The stuff I work on outside of work is usually where I get to write clean
code.

> (or my comments got ignored altogether)

Basically, it boils down to this. I don't know how people cope with it, at
times I feel totally hopeless about it. I see people sprinting towards the
cliff edge and no matter how much I try stop them, they are determined to keep
going. Sometimes it feels like they double down or deliberately do the
opposite of what I'm suggesting.

    
    
      Me: Hey, stop hitting yourself, that's bad.
      Them: Oh, you want me to stop hitting myself? I'm going to do it harder.

It's a totally uphill battle, some people just don't want to listen. I'm all
out of answers.

------
boyadjian
For me, the most violated, and least understood principle is "Liskov
Substitution Principle". How many times, I saw in a big software, inheritance
used to "modify" a base class. This is terrible programming.

------
lerax
Nice examples.

