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

51–60 of 154 posts

Re: Good refactoring vs. bad refactoring

#51

Post by creesch »

I am not sure if I agree with the article, however I do agree that not every time code actually needs to be formatted.

> More than a few of them have come in with a strong belief that our code needed heavy refactoring.

The code might, but a blind spot for many developers is that just because they are not familiar with the code doesn't mean it is bad code. A lot of refactoring arguments I have seen over the years do boil down to "well, I just don't like the code" and are often made when someone just joins a team at a point where they haven't really had time to familiarize themselves with it.

The first point of the article sort of touches on this, but imho mainly misses the point. In a few teams I worked in we had a basic rule where you were not allowed to propose extensive refactoring in the months (3 or more) of being on the team. More specifically, you would be allowed to talk about it and brainstorm a bit but it would not be considered on the backlog or in sprints. After that, any proposal would be seriously considered. This was with various different types of applications, different languages and differently structured code. As it turned out, most of the time if they already did propose a refactor, it was severely scaled down from what they initially had in mind. Simply because they had worked with the code, gained a better understanding of why things were structured in certain ways and overall gotten more familiar with it. More importantly, the one time someone still proposed a more extensive refactoring of a certain code base it was much more tailored to the specific situation and environment as it otherwise would have been.

Edit: Looks like it is being touched on in the fourth point which I glossed over. I would have started with it rather than make this list of snippeted examples.

Re: Good refactoring vs. bad refactoring

#52

Post by gcarvalho »

sevnin wrote: post #50
kolme wrote: post #44

Earlier quoted context omitted.

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.

I think it’s widely accepted that refactors should not change behavior. That’s my experience, at least.

Re: Good refactoring vs. bad refactoring

#53

Post by harperlee »

vasco wrote: post #13
zahlman wrote: post #11

Earlier quoted context omitted.

> I am under the impression that people start programming, by and large, with imperative for/if style => so the imperative style is readable by more people. IMO, this is a simple consequence of technology moving faster than society. There are still instructors out there who learned to program in an environment where the go-to options for imperative programming were C and FORTRAN; the go-to options for other paradigms…

People think imperatively though. If I think of visiting my friend, grabbing gas on the way back, the way I'll visualize the steps is not functional.

I dont know a lot about the brain but I do know that people that research modeling brains have used models in which there are two types of things to think: declarative things AND procedural things. See SOAR and ACT-R.

The caveat here is to which extent computers have tinted their models of a brain, but they are professional cognitive researchers so I’d give them the benefit of the doubt :)

Re: Good refactoring vs. bad refactoring

#54

Post by nxicvyvy »

sevnin wrote: post #50
kolme wrote: post #44

Earlier quoted context omitted.

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.

That's the definition most people use.

https://www.google.com/search?q=refactoring%20definition

Re: Good refactoring vs. bad refactoring

#55

Post by math_dandy »

The_Colonel wrote: post #14
p2501 wrote: post #4

Earlier quoted context omitted.

Aesthetic aside, I am under the impression that people start programming, by and large, with imperative for/if style => so the imperative style is readable by more people. Even for more experienced programmers, reading imperative probably cost less energy, since it is more internalised? Futhermore, in JS, the functionnal style is less performant (nearly twice on my machine, i assume because it do less useless memory…

> Even for more experienced programmers, reading imperative probably cost less energy, since it is more internalised? I disagree. For-cycles are usually more difficult to reason about, because they're more general and powerful. If I see "for (...", I only know that the subsequent code will iterate, but the actual meaning has to be inferred from the content. Meanwhile, a .map() or .filter() already give me hints - the…

No need to fear mutable local state. Shared state is where immutable data structures really shine.

Re: Good refactoring vs. bad refactoring

#56

Post by Diggsey »

MattHeard wrote: post #45

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 legi…

> Putting aside the mis-application of "pattern" (which _should_ be used with respect to a specific design problem, per the Gang of Four)

This is not in any way a mis-application of the word "pattern". There is no exhaustive list of all design patterns. A design pattern is any pattern that is used throughout a codebase in order to leverage an existing concept rather than invent a new one each time. The pattern need not exist outside the codebase.

> Consistency increases legibility, but only to a certain point.

It's the opposite: inconsistency decreases legibility, and there is no limit. More inconsistency is always worse, but it may be traded off in small amounts for other benefits.

Take your example of experimenting with new solutions: in this case you are introducing inconsistency in exchange for learning whether the new solution is an improvement. However, once you have learned that, the inconsistency is simply debt. A decision should be made to either apply the solution everywhere, or roll back to the original solution. This is precisely the point the author is making by saying "consider refactoring the entire codebase to use this new pattern".

This refactoring or removal doesn't need to happen overnight, but it needs to happen before too many more experiments are committed to. Instead what often happens is that this debt is simply never paid, and the codebase fills with a history of failed experiments, and the entire thing becomes an unworkable mess.

Re: Good refactoring vs. bad refactoring

#57

Post by whilenot-dev »

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.

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

Refactoring does not change the external behavior. If you can't change the internal behavior, then you can't reduce complexity.

So with that in mind...

- changing implicit caching => refactoring

- changing implicit timeouts => refactoring

- changing explicit caching => more than refactoring

- changing explicit timeouts => more than refactoring

Because the word external implies conceptual boundaries, I would personally also distinguish refactoring by levels:

- system design

- service design

- program design

- component design

- module design

- function design

...where this blog post only talks about the latter two.

Re: Good refactoring vs. bad refactoring

#58

Post by [deleted] »

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…

[deleted]

Re: Good refactoring vs. bad refactoring

#59

Post by Y_Y »

MattHeard wrote: post #45

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 legi…

> "pattern" (which _should_ be used with respect to a specific design problem, per the Gang of Four)

Why is that true? Particularly if you're not an OOP user/believer. It's not like "pattern" is some obscure term of art.

Re: Good refactoring vs. bad refactoring

#60

Post by sevnin »

gcarvalho wrote: post #52
sevnin wrote: post #50

Earlier quoted context omitted.

"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.

I think it’s widely accepted that refactors should not change behavior. That’s my experience, at least.

Huh, I guess that's true, even on wikipedia. I will have to stop using the word then. Though I'm pretty sure most people use it in day-to-day with much more abandon.
Post reply on HN