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

41–50 of 154 posts

Re: Good refactoring vs. bad refactoring

#41

Post by exe34 »

mariopt wrote: post #34

Words can not express my hate for this kind of articles. Imagine working on a legacy codebase where the PM holds the dogma of refactoring being a bad thing and expecting you to do it wrong, even micro managing your PRs. Most often than not, I do see projects suffering and coders actually resigning due to a lack of internal discussing about best practices, having space/time to test potential solutions, having Lead dev…

more people just means more time spent trying to coordinate and in the limit, you spend all the time talking and none coding.

Re: Good refactoring vs. bad refactoring

#42

Post by remus »

mariopt wrote: post #34

Words can not express my hate for this kind of articles. Imagine working on a legacy codebase where the PM holds the dogma of refactoring being a bad thing and expecting you to do it wrong, even micro managing your PRs. Most often than not, I do see projects suffering and coders actually resigning due to a lack of internal discussing about best practices, having space/time to test potential solutions, having Lead dev…

> Imagine working on a legacy codebase where the PM holds the dogma of refactoring being a bad thing and expecting you to do it wrong, even micro managing your PRs.

I don't think the article said that anywhere? It was just a list of some common things that can go wrong when refactoring, along with some examples.

Re: Good refactoring vs. bad refactoring

#43

Post by kolme »

azangru wrote: post #30

The first example of a good refactor is a meh refactor at best, and possibly a bad refactor. Array methods such as map or filter are not "more conventional" in javascript; they are "as conventional" as for-loops, and arguably less "conventional", given how for-loops have been around since the introduction of the language. They are also inevitably more expensive than for-loops (every cycle creates an anonymous functio…

> every cycle creates an anonymous function

No, that's not how it works. The function is evaluated once before the call and passed as an argument, then internally reused.

Also, you're microptimizing. Prioritizing supposed performance over readability.

And yes, for-loops and mutable structures are more error prone than map-filter-reduce. The original is OK but could be better.

Re: Good refactoring vs. bad refactoring

#44

Post by kolme »

jv_be wrote: post #28

A good refactor does not change behaviour, I would like the author to start with that point. Take many more much smaller steps while doing so. Not touching a piece of code in the first 6 to 9 months is something I don’t really agree with. Breaking complex methods up by extracting variables and methods can really help learning the code, whilst not breaking it. If you are worried about consistency, just pair up of prac…

A refactor does not change behavior, period. By definition.

If something changed, it's not a refactor. It's a change.

Like in the example where the caching was removed: NOT a refactor.

Ore where the timeouts for the requests were changed: NOT a refactor.

The definition of refactor: change the structure of the code without altering the behavior.

It's like saying a crash is a bad landing.

Re: Good refactoring vs. bad refactoring

#45

Post by MattHeard »

I got as far as here:

> If you need to introduce a new pattern, consider refactoring the entire codebase to use this new pattern, rather than creating one-off inconsistencies.

Putting aside the mis-application of "pattern" (which _should_ be used with respect to a specific design problem, per the Gang of Four), this suggestion to "refactor the entire codebase" is impractical and calcifying.

Consistency increases legibility, but only to a certain point. If the problems that your software is trying to solve drift (as they always do with successful software), the solutions that your software employs must also shift accordingly. You can do this gradually, experimenting with possible new solutions and implementations and patterns, as you get a feel for the new problems you are solving, or you can insist on "consistency" and then find yourself having to perform a Big Rewrite under unrealistic pressure.

Re: Good refactoring vs. bad refactoring

#46

Post by kolme »

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 because that's not even what we call refactoring.

Edit: removed unnecessary negativity.

Re: Good refactoring vs. bad refactoring

#49

Post by asp_hornet »

knallfrosch wrote: post #37
azangru wrote: post #30

The first example of a good refactor is a meh refactor at best, and possibly a bad refactor. Array methods such as map or filter are not "more conventional" in javascript; they are "as conventional" as for-loops, and arguably less "conventional", given how for-loops have been around since the introduction of the language. They are also inevitably more expensive than for-loops (every cycle creates an anonymous functio…

Disagree on this. filter and map are much more readable and especially extensible than result-arrays. Plus it eliminates out-of-bonds indexing. See the variable name. It's forced to be 'result' so that it's consistent with the result-array style. Therefore it lacks a descriptive name. For the functional methods, you can easily assign the filter(age > 18) result to an intermediate variable like adultUsers to make the…

> much more readable

That’s down to preference.

Doesnt both filter and map copy the array increasing gc pressure?

Re: Good refactoring vs. bad refactoring

#50

Post by sevnin »

kolme wrote: post #44
jv_be wrote: post #28

A good refactor does not change behaviour, I would like the author to start with that point. Take many more much smaller steps while doing so. Not touching a piece of code in the first 6 to 9 months is something I don’t really agree with. Breaking complex methods up by extracting variables and methods can really help learning the code, whilst not breaking it. If you are worried about consistency, just pair up of prac…

A refactor does not change behavior, period . By definition. If something changed, it's not a refactor. It's a change. Like in the example where the caching was removed: NOT a refactor. Ore where the timeouts for the requests were changed: NOT a refactor. The definition of refactor: change the structure of the code without altering the behavior. It's like saying a crash is a bad landing.

"By definition" proceeds to define the word in a way that most people won't agree with. Okay mate. Your definition is ass. The person that wrote the article doesn't agree with you, I don't agree with you. I will still use the word refactor when I talk about simplifying the application such that code becomes simpler through simplifying and improving the design.
Post reply on HN