Live data from Hacker News

Solid and Clean Code never felt solid or clean to me

devz.cl

51–60 of 82 posts

Re: Solid and Clean Code never felt solid or clean to me

#51
post #6

I clicked the link hoping for a critique of the ideas in SOLID and Clean Code, but what I got was an ironically long-winded critique of Bob Martin’s speaking style. Martin and I have our differences, but this article isn’t really useful. Martin has a brand and a style. A lot of people find it engaging and entertaining. If you don’t, that’s fine, there’s plenty of other ways to learn about the ideas that are more conc…

> [..] There’s plenty of other ways to learn about the ideas that are more concise. Would you have any good resources to share?

I’m not really a fan of the ideas. They’re not wrong, exactly, but I think they’re overstated. Instead, here’s some alternatives:

For design, Evans’ Domain-Driven Design does a good job of representing classic object-oriented design, and Fowler’s Patterns of Enterprise Application Architecture is good for expanding past business logic to larger systems.

For coding habits, “The Pragmatic Programmer” is a classic for a reason.

Re: Solid and Clean Code never felt solid or clean to me

#52

The #1 problem of most clean code, or microservices, or other architectural patterns is taking a correct observation to a logical extreme. Decomposition is good. Too much decomposition recreates complexity in the interactions. Immutability is good. Immutability everywhere creates gymnastics with more mental load. Extensibility is good. Extensible-everything is reduces usability. Program isolation is good. Too much is…

I fully agree.

I think a major meta-problem with patterns is that the straight-forward ones get written about the most, and/or read about the most. Now we have tons of devs out there who pledge allegiance to some subset of whatever patterns they've come across. I wonder if that prevents/delays pattern transcendence to see the nuance.

Re: Solid and Clean Code never felt solid or clean to me

#53

Choose a convention and stick with it. Your chosen conventions could be the worst fit for your domain, but the code following "a" convention ensures that people jumping in later can actually follow along and it makes refactoring at least bearable. I personally don't like when people stick to SOLID like it's the holy hammer, but nearly every serious programming language has a convention on how to write SOLID code, and…

I tend to agree with this take. If you do something wrong at least doing it consistently will be more valuable than not. Unfortunately dogma is not easy to avoid. Even it wasn't for Bob's Clean Code, some other guy would distill some patterns, market another book with a catchy title that'd be inevitably somewhat misunderstood and misused.

Re: Solid and Clean Code never felt solid or clean to me

#54
post #18

What I dislike about the term "clean" code is that it dismiss objective criteria. "I did it like that because it's cleaner" is a non sense. A program must be maintenable, efficient, observable, testable, scalable, performant, readable, secured. Each criteria can be objectively measured in a kind of radar diagram and can be maximized as long as it does not sacrifice another criteria. Form follows function. Even "simpl…

> "I did it like that because it's cleaner" is a non sense. A program must be maintenable, efficient, observable, testable, scalable, performant, readable, secured. Each criteria can be objectively measured in a kind of radar diagram and can be maximized as long as it does not sacrifice another criteria. Form follows function.

I don't think it's nonsense. "Cleaner" here is just a different word that falls under your categories of readable and maintainable. More toward readable. Different word, same meaning.

Re: Solid and Clean Code never felt solid or clean to me

#55

I guess by now it's pretty settled down and unanimous that SOLID is an extremely bad way to organize your code, and that Clean isn't very good and has about the same odds of helping or harming you. But extending the complaint to all acronyms isn't helpful. ACID, OLAP, EBITDA, etc are perfectly good names with clear meanings that can be easily discovered.

I'm not sure you can even get majority agreement of what SOLID code looks like, let along unanimous agreement on it being bad.

Re: Solid and Clean Code never felt solid or clean to me

#56
post #47

I've yet to find a panacea. For example, I thought DRY was, but found its not the case (test scenarios). I've yet to find altruisms past "everything in moderation". If you do choose a style and stick to it though at least it's consistent.

> I've yet to find a panacea. For example, I thought DRY was, but found its not the case (test scenarios).

What would it have meant for DRY to be a panacea? That doesn't make much sense.

Re: Solid and Clean Code never felt solid or clean to me

#57

The #1 problem of most clean code, or microservices, or other architectural patterns is taking a correct observation to a logical extreme. Decomposition is good. Too much decomposition recreates complexity in the interactions. Immutability is good. Immutability everywhere creates gymnastics with more mental load. Extensibility is good. Extensible-everything is reduces usability. Program isolation is good. Too much is…

Yeah, don't take it too far.

You can reduce to a Single Responsibility, but try not to step beyond that into Zero Responsibility.

Do Interface Segregation, not Interface Apartheid.

And only invert your dependencies an odd number of times, otherwise you're back to where you started.

Re: Solid and Clean Code never felt solid or clean to me

#58

I am sorry but nothing in the article clearly lays out how solid/clean code doesn't feel solid or clean. It seems to be a criticism of a specific person. What am I missing?

Every webdev team out there is doing the same architectural fuckup : using exactly one database, and coupling everything to that. The Controller points straight at the Service which points straight at the DB. Even the basic units of your logic (User, Payment, Document) do not exist without reference to the (ONE) DB. They're called 'Entities'.

It's a nightmare to test. Every click of a 'unit' test requires the database to stand up, be initialised (check its 'Migrations' have been run, if not actually running them), cleaned up afterward, and maybe a few microseconds of that time will be used for testing your logic.

(I don't know what the equivalent frontend fuckup would be - running every unit test through the browser? digression..)

Architecturally it means you can't change dependencies. Do you want a cache in addition to the DB? Kafka? NoSql? A strangler or sidecar pattern where you live-live migrate from one system to another with no down-time? If you manage your dependencies, these are all do-able ideas. If you don't, they are impossible to do, and then, through the lens of all-classes-belong-to-the-one-true-database, you'll perceive those other ideas as terrible, even though it's actually your architecture which is terrible.

DIP says to guard against these kinds of things. Look inside your TaxService and TaxRule classes - you should not see any direct or indirect dependencies to database code. (Just like you shouldn't see any references to the Browser, the DOM, or Kubernetes.)

No dependencies means you can run all 30-50 unit tests in your TaxServiceTests in about 10 millis, and in parallel with whatever other tests are going on.

----

Now take a step back. Everything I wrote above is just the D in SOLID. (And I didn't even get to 'how to do it'; I only covered 'why' and 'how to check if you did it')

Do you see anyone actually engaging with these concepts? cos I don't.

There is a much lower barrier to entry in saying:

"I saw my teammate try to do SOLID and it was the worst so I always avoid it"

"Bob is a right-wing weirdo!"

"SOLID is dogma and it's bad to be dogmatic so SOLID is bad"

"I like a bit of SOLID but NOT TOO MUCH because I'm a pragmatic person"

If you look at the actual principles, what the hell does that last one mean? You only need to maybe stand up the database a little bit to check your tax logic?

Re: Solid and Clean Code never felt solid or clean to me

#59
post #18

What I dislike about the term "clean" code is that it dismiss objective criteria. "I did it like that because it's cleaner" is a non sense. A program must be maintenable, efficient, observable, testable, scalable, performant, readable, secured. Each criteria can be objectively measured in a kind of radar diagram and can be maximized as long as it does not sacrifice another criteria. Form follows function. Even "simpl…

> "I did it like that because it's cleaner" is a non sense. A program must be maintenable, efficient, observable, testable, scalable, performant, readable, secured. Each criteria can be objectively measured in a kind of radar diagram and can be maximized as long as it does not sacrifice another criteria. Form follows function. I don't think it's nonsense. "Cleaner" here is just a different word that falls under your…

Yeah seriously what's the test of maintainable that couldn't be applied to the word clean?

What about the latest book Tidy First https://a.co/d/0b1hRqEV

Re: Solid and Clean Code never felt solid or clean to me

#60

Uncle Bob is a snake oil salesman. Not sure he realizes it himself though. The whole SOLID, OOP design patterns era was one of the worst things to have happened to programming. I always thought I was the one that sucked but now I'm absolutely certain that whole zeitgeist was total crap.

What do you prefer?
Post reply on HN