Live data from Hacker News

Solid and Clean Code never felt solid or clean to me

devz.cl

71–80 of 82 posts

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

#71
post #65
post #39

Earlier quoted context omitted.

Humans like acronyms. You see them all over. If it seems like programmers like them more than others it is only because you are in that field and don't think about other fields. (did you know that Radar, and Scuba are acronyms? probably most readers do as soon as I pointed it out but if asked to come up with a non-programming acronym would have used others)

>Humans like acronyms. Americans, mostly. I don't really know why but acronyms are a very american thing.

HLA

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

#72
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…

He seems to prefer being called Uncle Bob.

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

#73

Earlier quoted context omitted.

Regardless of style, Uncle Bob's Enterprise Java Clean Code opinions are overly dogmatic and harmful in most places.

I pick and choose the bits I think make reasonable sense, an go with better options myself.

This is the right approach, unfortunately many of my coworkers in software are ridiculously dogmatic about it

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

#74

Earlier quoted context omitted.

> [..] 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…

Thanks for the tips!

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

#75

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.

"Extremely bad"? What are the actual material consequences of the decision? Relate it to business outcomes

Why are you talking to the OP like they're a bot?

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

#76
post #30

For some actual code and comparison of principles behind Clean Code see: https://github.com/johnousterhout/aposd-vs-clean-code

And at the end of that Bob says: > For my part I'll just say that I have given due consideration to the points you've made, and while I disagree with your conclusions above, I have integrated several of your better ideas, as well as this entire document, into the second edition of Clean Code.

Much faster and more efficient and better to just buy a copy of:

https://www.goodreads.com/en/book/show/39996759-a-philosophy...

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

#77
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…

I found this https://vimeo.com/157708450 video quite interesting critique of SOLID.

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

#78

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.

> Uncle Bob is a snake oil salesman

I think it's not as bad as a snake oil salesman that knew their product was not good.

In reality, most software design and dev advice is well intentioned but is just based on personal opinion, they don't really have much science behind them.

This is not to say they should be completely ignored, it means there should be a healthy does of using your own brain and experience on any of this stuff.

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

#79
post #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 databas…

In frontend it's coupling everything to specific backend urls and it's literally billion times worse. People fire up a frigging headless browser and set up backend servers to test a few microseconds of logic. You don't get to test much at all before everything takes too long and becomes too flaky.

At best solid haters/unaware will "solve" this by mocking everything, which just has a different set of problems and is just as bad. The only way to truly have actual satisfying solution is DI.

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

#80
post #32

Earlier quoted context omitted.

The trouble with SOLID is that it's mainly an artifact of old languages and paradigms. 3 of the letters are almost irrelevant in modern code, or barely worth thinking about most of the time. So what's the value here? Single responsibility? That kind of thing is now so known that it doesn't really need talking about, like you don't really need to endlessly discuss the database normal forms like people did in the 00s.…

If single responsibility is so well known, when did I just this week see some code that violated that from a senior engineer? That code past review by a couple other programmers, without me looking at it and pointing out how horrible it was.

And I saw a "senior" engineer make a database table without foreign keys just 3 years ago.

Some people are just bad.

Doesn't change my point that the debate is long settled, SRP is incredibly well known and the de-facto way of coding today.

Post reply on HN