SOLID is a nice sets of principles. And like principles, there are valid reasons to break them. To use or not to use is a decision best taken after you’ve become a master, when you know the tradeoffs and costs.
Learn the rules first, then learn when to break them.
I actually sat down to really learn what SOLID meant a few years ago when I was getting a new contract and it came up in a few job descriptions. Must have some deep wisdom if everyone wants SOLID code, right?
At least two parts of the SOLID acronym are basically anachronisms, nonsense in modern coding (O + L). And I is basically handled for you with DI frameworks. D doesn't mean what most people think it does.
S is the only bit left and it's pretty much open to interpretation.
I don't really see them as anything meaningful, these days it's basically just make your classes have a single responsibility. It's on a level of KISS, but less general.
Looks like for you SOLID is just so obvious and easy that it's not worth even thinking about. Maybe that's a sign you're working on code that is already adherent to it.
Try working on projects that are violently against it, while still being a classic Java-like codebase to appreciate it.
I work on a big codebase, where most of the code is in Singletons and static methods, no interfaces, no DI frameworks. Maintaining this system and making serious modifications to it is a serious engineering effort, adding weeks to simple changes.
I'm really not. Most of the code I have worked on in my career was hodge podge code, or written by ridiculously unqualified programmers. Sometimes it has been 10-15 years old. At one place the external agency who'd written one of the systems were so bad that they had a project per class. One project, one class file. And no-one had noticed in 5 years, they just thought it was somehow necessary!
Part of what makes my clients happy is that I deliver changes and new features consistently. What I don't always tell them is that after my first 3 months I will start ripping out huge swathes of their old code and replacing it with 1/10th the amount of code that was there. Sometimes I do, depends on the client.
The recent codebase I worked on was using what I consider one of the worst patterns I've ever seen, CSLA. Everything used it. Absurdly hard to work with, practically designed to be inscrutable. It was also littered with static methods everywhere, impossible to use DI with. The gig before that some prat had used the mediator pattern for simple CRUD forms.
2 years later and there's not a single CSLA pattern left and only a few static methods in 'critical' code paths that I haven't got round to extricating. We can use modern libraries, everything is DI, and have switched from framework 4.7 to Core .Net 8.
In the past I've migrated webforms to MVC, migrated from one database system to a different (surprisingly easy) and switched whole front-end frameworks.
It is a serious effort to fix architectural problems. But you turn it in a manageable effort by chipping away at it. By starting on one system and spreading.
That webforms to MVC? It started with one MVC endpoint for a new backend admin feature. Non-critical, but can I run an MVC project inside a webforms project. As soon as I could run the two side-by-side every new feature was an excuse to migrate a page to MVC, it didn't add much time. A year later, bye-bye webforms. Hello, development velocity.
Lots of programmers will not even attempt to fix architectural rot and just wallow in it.
I have advantages, often I'm a team of one, or two, or three and can bully my way through middle management to change. Yes. Weird career. I'm not going to lie, every now and then I'm 80% through a refactor with a deadline looming and I hate myself and despair. But it usually works out.
But you sound so resigned? If you were in my position, would you listen to my opinion about SOLID if I'd just admitted I was wallowing in the rot? You don't sound like a top tier programmer.
Try fixing it! That's how you learn what actually works in architecture. That's when you can start having an opinion about architecture.
This is idealistic. Do you actually sit down and evaluate whether the code is SOLID or maybe it's more like you're just vibe checking it, and it doesn't actually matter if you call that SOLID or DRY or whatever letters of the alphabet you prefer. Meanwhile your project is just a PostgreSQL proxy.
These are principles, not mathematical equations. It’s like drawing an human face. The general rule is that the eyes are spaced by another eye length viewed from the front. Or the intervals between the chin, the base of the nose, the eyebrows and the hairline are equal. It does not fit every face, and artists do break these rules. But a beginner breaks them for the wrong reasons.
So there’s a lot of heuristics in code’s quality. But some time, it’s just plain bad.
Learn the rules first, then learn when to break them.