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

81–90 of 224 posts

Re: Goodbye, Clean Code (2020)

#81

Post by Cthulhu_ »

VBprogrammer wrote: post #34
pydry wrote: post #4

This blog is essentially a journey of self discovery arriving at https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction "duplication is far cheaper than the wrong abstraction."

The thing I hate most is when some creates the "new way of doing things". Then fails to convert most of the existing code which is "doing things the old way" even when it's clear that it is the same thing.

The pitfall there - and I myself am guilty of this - is that you only apply it halfway, so instead of fixing the problem (if there even is one), you're left with two different approaches to the same problem, meaning you added a second problem as well as a lot of overhead because you're not maintaining two different solutions.

Re: Goodbye, Clean Code (2020)

#82

Post by Cthulhu_ »

agumonkey wrote: post #44
regnull wrote: post #25

Having duplication does not mean your code is not clean. Sometimes, having duplication is actually cleaner, and easier to understand. Removing duplication may introduce complexities, and force developers to untangle the additional logic that was introduced to remove dupes. Good duplication means code just happened to be the same in a few places (but it can be potentially different). It's fine and easy to read. On the…

Would you go with a simple comment/tag to denote both piece of code are identical but not abstracted away on purpose ?

Some IDE's and external tools have duplication detection; I mean it probably won't be enough for people to go 'if I fix it here, I should fix it there' if it applies to both locations, but still.

Re: Goodbye, Clean Code (2020)

#83

Post by rootusrootus »

marginalia_nu wrote: post #65
Dudeman112 wrote: post #62

Earlier quoted context omitted.

And yet, at least for the quoted part, he is right. It requires some massive balls to deploy code to production while not even seeing if it works for any case. If the answer to "how do you know it works?" is "trust my judgement bro" then I will not, in fact, trust their judgement. I do agree he has a finger in the zealotry and he should probably have modulated how he expressed himself.

You know, they sent people to the moon using software written before the unit test paradigm.

Way, way back in the day, one of the best applications I've ever written had no tests. That application is probably in use today, in fact, even though its life is measured in decades. My takeaway is that tests are important, but good code is still more important.

Re: Goodbye, Clean Code (2020)

#84

Post by lowercased »

shikoba wrote: post #67
lowercased wrote: post #61

Earlier quoted context omitted.

Years ago (2005?) I worked at a call center. Most agents were on one coast - data center was in another coast. Agents in our call center complained about speed. When they'd pull up an account, it was taking seconds... sometimes 15-20 seconds... to pull up the account. This was all a bespoke CRM system. I poked in the code (it was something I had access to) and noticed that ... the entirety of the whole screen was dup…

You mailed the original developer, he didn't answer. And you were fired for doing your job right. What you must conclude is that they don't care about quality but about ego. They have a philosophy that don't favor quality. You should be glad they fired you.

I wasn't fired, just... the threat was raised. That original dev left soon after (in no way related to that - he'd been looking around for a while from what I heard). It was a strange situation because in the group of... 8 or 9 of us, I was the last one in, and got along OK with everyone, except him.

Re: Goodbye, Clean Code (2020)

#85

Post by gchamonlive »

pelasaco wrote: post #80

I'm shocked that from all discussion nobody noted the root of all evil: "It was already late at night (I got carried away). I checked in my refactoring to master and went to bed, proud of how I untangled my colleague’s messy code." No PR, no code review, no CI. Just a cowboy pushing to the master..

And using clean code wrong. Clean code is not a panacea. If people use it as such and without the correct agile rites, they should do it at their own peril, but blaming it on clean code is at the very least naive (and somewhat dishonest)

Re: Goodbye, Clean Code (2020)

#86

Post by ThaJay »

datavirtue wrote: post #55
emerongi wrote: post #26

Earlier quoted context omitted.

The other developer usually has reasons why they designed it that way. If you just rewrite other people's code, it makes it seem like you think there is One True Way to writing code and that you're smarter than them. I'd ask first if they agree with a certain improvement. It shows I value them as an engineer and they might bring up critical information that I'm missing, making my "improvement" actually worse. It does…

I just assume that they got one pass at it. Agile!!

I agree Agile steers a team towards hastily bodged together code.

Re: Goodbye, Clean Code (2020)

#87

Post by muzani »

IMO ideal code is code that looks like the problem it's trying to solve. Really good code will be faster to write than the user stories; it resembles pseudocode.

A lot of bad refactoring is sort of like putting Chair as a subclass of Dog because both have four legs. Or someone thinking that long paragraphs have high cognitive load, so all paragraphs are split into 2-3 lines.

In this scenario, OP simply changed the code without understanding what problem it was meant to solve. It's not about trading readability for flexibility, or respect or anything. It's that the code was probably further from solving the problem.

Re: Goodbye, Clean Code (2020)

#88

Post by marginalia_nu »

rootusrootus wrote: post #83
marginalia_nu wrote: post #65

Earlier quoted context omitted.

You know, they sent people to the moon using software written before the unit test paradigm.

Way, way back in the day, one of the best applications I've ever written had no tests. That application is probably in use today, in fact, even though its life is measured in decades. My takeaway is that tests are important, but good code is still more important.

What I really wanted to say is that there is more than one way of knowing whether code works. Unit testing is one paradigm.

Just because Uncle Bob, seller of unit testing software and TDD-books will hear of no other doesn't mean that this is the One True Way.

Re: Goodbye, Clean Code (2020)

#89

Post by emaginniss »

VBprogrammer wrote: post #34
pydry wrote: post #4

This blog is essentially a journey of self discovery arriving at https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction "duplication is far cheaper than the wrong abstraction."

The thing I hate most is when some creates the "new way of doing things". Then fails to convert most of the existing code which is "doing things the old way" even when it's clear that it is the same thing.

That's essentially the lava flow anti-pattern. You have remnants of old architect/tools/philosophy left in the old code while the new code is being built with the new hotness. Invariably everyone has to learn the old stuff to maintain the system as well as learn the new stuff to keep building.
Post reply on HN