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

Good refactoring vs. bad refactoring

builder.io

Post reply on HN
Print view View original

121–130 of 154 posts

Re: Good refactoring vs. bad refactoring

#121

Post by 8n4vidtmkvmk »

sidmitra wrote: post #96
charlie0 wrote: post #92

Earlier quoted context omitted.

It's not that it wouldn't be applied to the whole codebase, it's that it wouldn't be applied to the whole codebase __at once__. You have to start somewhere and new features are a good place to start new patterns. Older code can be refactored piece by piece.

I've had success with strategies at introducing some abstractions/patterns at my current place(doing this alone for a enterprise SaaS company with 200-ish devs). It's weird that we don't teach these or talk about them in software engineering(AFAIK). I see them being re-invented all the time. To borrow from medicine: First step is to always stop the `stop the hemorrhage`, then clean the wound, and then protect the wou…

> test cases might have owners

I hope the owner is the same person that owns the code.

Re: Good refactoring vs. bad refactoring

#122

Post by idrios »

I hate this article. It's a very smug way of blaming the dev who's just trying to make the app better when it's probably the culture that's the problem. Bad refactors usually happen because the person doing the refactor is getting a ton of pushback on it -- they probably underestimated the effort involved and are getting chewed out for taking too long on it, so they cut corners that might accidentally lose functionality, or they don't finish the desired abstraction / clean code they were going for which leaves the code less readable.

For a dev that's a new hire, refactoring the code is also a way for them to feel ownership over it. The PM should be happy that they're thinking about the way the code works and the way the code should work. It's on the company to have review & qa processes that catch problems before they lead to downtime.

I don't disagree that some of the examples given are bad refactors, but in regards to adding inconsistency I see that happen a lot more when rushing out new features or bug fixes than when refactoring; usually the refactor is the effort trying to establish some kind of consistency. And example 5 isn't a refactor it's just removing functionality. If that was the intent, the person should be told not to do that. If it's an accidental side effect of some larger refactor effort, then just add the functionality back in a new PR. Accept that mistakes happen, adopt some QA controls to catch them, and build a culture that encourages your developers to care about your product.

Re: Good refactoring vs. bad refactoring

#123

Post by move-on-by »

doctorM wrote: post #88

Reading this I realised I've kind of drifted away from the idea of refactoring for the point of it. The example with the for-loop vs. map/filter in particular - it's such a micro-function that whichever the original author chose is probably fine. (And I would be suspicious of a developer who claimed that one is 'objectively' better than the other in a codebase that doesn't have an established style one way or the oth…

I agree! No one wants to review unnecessary stylistic changes.

> it should have been caught in code review in the first place

There is probably a ticket rotting in someone’s backlog to ‘clean it up’, unless someone declared ticket bankruptcy.

Re: Good refactoring vs. bad refactoring

#124

Post by _a_a_a_ »

Y_Y wrote: post #119
_a_a_a_ wrote: post #84

Earlier quoted context omitted.

For consistency, the same design problems should have the same design solutions a.k.a. pattern. If you don't value consistency, feel free to take a different approach every time. That will confuse your users. I used to work with a guy, the simple problem of reading a CSV was done using a library, problem sorted. Out of sheer excitement he then rewrote it was with combinator parsers, then as some astronaut architect f…

Are you replying to the right person? I'm saying that "pattern" need not be restricted to the narrow sense used in the famous "Gang of Four" book[0], not that patterns are inherently bad! [0] https://www.oreilly.com/library/view/design-patterns-element...

> I'm saying that "pattern" need not be restricted to the narrow sense used in the famous "Gang of Four" book

I understood that was exactly what you were saying! Sorry, I'd had a drink.

Re: Good refactoring vs. bad refactoring

#126

Post by nuancebydefault »

nine_k wrote: post #101
nuancebydefault wrote: post #87

Earlier quoted context omitted.

The second code does not compile and introduces a new dependency.

Sorry, are we speaking about the same language? https://www.typescriptlang.org/play/?#code/MYewdgzgLgBCA2ATA...

My apologies, I thought it was C++. I should learn typescript, it is one of those I'm postponing.

Re: Good refactoring vs. bad refactoring

#127

Post by klibertp »

skybrian wrote: post #71
Jean-Papoulos wrote: post #40

Earlier quoted context omitted.

That's because they are. Functional code is more readable. And if you look back, basically all advances in programming languages have been about "making stuff more readable". Thus, for loops (for this usage) are "old".

You say it’s more readable and I disagree with that! Is this just fashion? Is there a way to settle it other than “I like it better?”

> Is this just fashion?

Yes.

Readability is a characteristic of the reader, not what is being read.

This simple truth seems to be so hard for many people to internalize. My theory as to why is that most programmers never get exposed to drastically different and unfamiliar languages and styles of programming. If they were forced to confront and internalize 2-3 different ways of writing code, they would realize this truth.

Personally, I once thought Lisp was unreadable... until I learned it. I once thought BASH was unreadable... until I learned it. Same with half a dozen other languages. Same for styles. "Readability" is just a familiarity and proficiency of the reader.

Re: Good refactoring vs. bad refactoring

#128

Post by eithed »

_a_a_a_ wrote: post #108
conceptme wrote: post #104

Earlier quoted context omitted.

Other goals can be performance, testability

Testability is a good one, thanks. I'm not so sure about performance and I'll chew that one over for now.

Imagine that you've refactored code and reduced complexity, but also reduced performance (the caching example) - would you move forward with the refactor?

From my perspective there should always be a buy in - after refactoring the system is more understandable, but also more coupled. Is this fine? If no, can given refactor be merged now and result tackled in separate refactor. Caching refactor can have a buy in as well - ie. remove caching because given request shouldn't be cached, or this functionality should be decoupled and done elsewhere

Re: Good refactoring vs. bad refactoring

#129

Post by ahoka »

boxed wrote: post #62
watwut wrote: post #22

Earlier quoted context omitted.

I think that was the point - the library added nothing, the same thing could be done with pure javascript.

If that was the point, then that paragraph needs to be rewritten badly.

It was quite obvious to me.

Re: Good refactoring vs. bad refactoring

#130

Post by ahoka »

kolme wrote: post #46

There was a great refactoring chance in the example where the cache was removed. That is, extracting the caching logic from the API call logic. Caching could have been a more generic function that wraps the API call function. That way each function does exactly one thing, and the caching bit can get reused somewhere else. Instead, this weird advice was given: changing behavior is bad refactoring. Which is weird becau…

Developers regularly make code changes that change behavior and insist that it’s refactoring.
Post reply on HN