Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, Clean Code (2020)

overreacted.io

Post reply on HN
Print view View original

11–20 of 224 posts

Re: Goodbye, Clean Code (2020)

#11

Post by UglyToad »

This seems close to illustrating a thought I've been toying with turning into a blog post but need some more examples of before I do:

"Abstract over data, not behaviour"

This seems to fall into the trap of abstracting over behaviour.

The best other example I've thought of for this is the 'generic repository pattern' common in C# and I'd guess Java. Just because CRUD on types is all similar behaviour you can't really build a generic/abstracted way of doing it, because at some point you need different behaviour in some update/insert depending on how the domain concept should act and then you're in a world of pain with a crappy abstraction.

One's code actually 'doing something' isn't a sign of unclean code, it's why one writes it. Stop trying to build abstractions that simplify the doing of what your code does.

Re: Goodbye, Clean Code (2020)

#12

Post by DeathArrow »

Uncle Bob fooled many developers to join his sect. I am much happier since I've discovered that there's not only "one true path" and OOP, SOLID and Clean Code are not the means to everything in software.

Re: Goodbye, Clean Code (2020)

#13

Post by V-2 »

"Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it."

While undeniably true, this feels completely orthogonal to the question of clean code. You could ruffle someone's feathers in the exact same way by taking code into the opposite direction.

"Goodbye, Clean Code [...] Don’t be a clean code zealot"

I agree with choosing pragmatism over purism. But the clickbaity title exercises a pattern I've seen hundreds of times, to which I have frankly become a bit allergic over the years: "X considered harmful! ...I mean, if you're overdoing X". Not being a healthy food zealot doesn't equal "goodbye, healthy food".

Re: Goodbye, Clean Code (2020)

#14

Post by shikoba »

breckenedge wrote: post #3

This article really buries the most important lesson about refactoring: > I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to e…

Why one should ask to the original developer if the code can be modified?

If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.

Re: Goodbye, Clean Code (2020)

#15

Post by extrememacaroni »

DeathArrow wrote: post #12

Uncle Bob fooled many developers to join his sect. I am much happier since I've discovered that there's not only "one true path" and OOP, SOLID and Clean Code are not the means to everything in software.

He makes money whenever he convinces someone he's right, of course he's convinced many to join his sect.

Re: Goodbye, Clean Code (2020)

#17

Post by sigzero »

shikoba wrote: post #14
breckenedge wrote: post #3

This article really buries the most important lesson about refactoring: > I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to e…

Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.

If they were still there, why wouldn't you engage them about a modification you think was better than the original? Everyone learns in that situation.

Re: Goodbye, Clean Code (2020)

#18

Post by breckenedge »

shikoba wrote: post #14
breckenedge wrote: post #3

This article really buries the most important lesson about refactoring: > I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to e…

Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.

Because it wasn’t necessarily an improvement on the original code. A discussion should have happened either during the original commit or before the refactoring commit.

Re: Goodbye, Clean Code (2020)

#19

Post by yuvalr1 »

DeathArrow wrote: post #12

Uncle Bob fooled many developers to join his sect. I am much happier since I've discovered that there's not only "one true path" and OOP, SOLID and Clean Code are not the means to everything in software.

This post is not related to Uncle Bob's book, which is not even mentioned. The term "clean" here is subjectively interpreted by the writer of the post.

Re: Goodbye, Clean Code (2020)

#20

Post by nibix »

shikoba wrote: post #14
breckenedge wrote: post #3

This article really buries the most important lesson about refactoring: > I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to e…

Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.

Trust would also include to consider that there might be a reason for why the code is the way it is, even if it is not directly obvious.

A brief chat can then help to clarify things.

Post reply on HN