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

141–150 of 154 posts

Re: Good refactoring vs. bad refactoring

#141

Post by madcocomo »

This is an interesting topic, but I don't think the article effectively conveys its message.

The title focuses on good and bad refactoring, but most of the content discusses good and bad design. This means that many of the bad examples are inherently bad, regardless of whether they were refactored from another version or written from scratch. The introductory comic and the conclusion mention how to perform refactoring, but the rest of the article drifts away from this and only discusses the resulting code. The first pitfall mentions changing the coding style, but the explanation actually addresses the problem of introducing external dependencies. The fifth point, "understand business context," should actually be "not understanding business context." If we perform refactoring incrementally, it's inevitable that there will be some inconsistencies during the process. Therefore, the third pitfall, "adding inconsistency," should include additional explanations.

In summary, I think the article would be more helpful if it focused more on how to perform refactoring rather than criticizing a specific piece of code.

Re: Good refactoring vs. bad refactoring

#142

Post by Izkata »

nuancebydefault wrote: post #126
nine_k wrote: post #101

Earlier quoted context omitted.

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.

Nothing in that snippet is Typescript-specific, it's just plain Javascript.

All syntactically valid Javascript is also syntactically valid Typescript, it just adds stuff, though you can get runtime errors for things like reassigning variables in a way Javascript is fine with that Typescript disallows.

Re: Good refactoring vs. bad refactoring

#143

Post by stickfigure »

strken wrote: post #97
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.

In the majority of places I've worked, nobody who started refactoring older code piece by piece ever finished it. The exception is people who documented the scope of the work, got leadership buy-in, and then worked on it continuously like any other project. The problem is that sometimes the new pattern gets overridden by an even newer pattern, and so on, until you've got three different implementations from 2016, 201…

In a sufficiently large codebase, this is just simply inevitable and you just have to accept it as a fact of life. If you have millions of lines of hand-written code, you're going to have archeological layers and some pockets that are more modern than others. It's not great but "everything is locked into a pattern established in 2003 and you can't innovate" is a worse problem.

Re: Good refactoring vs. bad refactoring

#144

Post by nuancebydefault »

xigoi wrote: post #137
nuancebydefault wrote: post #93

Earlier quoted context omitted.

If you change the polynomial, you change the order of calculations and hence change behaviour. You might get overflows in case of integers or different precision in case of floats. Nice to learn where the word originates from. Often the meaning of words change over time. E.g. today no horses need involved in bootstrapping.

A polynomial is a mathematical object. There are no integer overflows or float imprecisions in mathematics.

You are right but in fact the maths are only a means to an end, a model that isn't exactly equal to the final real world implementation in analog or digital electronics.

Re: Good refactoring vs. bad refactoring

#145

Post by pensatoio »

davidmurdoch wrote: post #107
pensatoio wrote: post #105

This code is unreadable chaos, before and after. This article just reminds me why I hate JavaScript so much. I know you frontend engineers can’t avoid it, but I wish we could come up with something better.

What languages do you like to spend time in?

Golang is my favorite right now, but I think it’s possible to create readable code in many languages, even ones I like less. The JavaScript and its ilk strike me as some of the worst of the “modern” languages. Again, no hate here. I started out with JS and PHP, 20 years ago. I just cringe any time I see modern JS syntax, and wish it were simpler so I could get back into it.

Re: Good refactoring vs. bad refactoring

#146

Post by achillesheels »

ggm wrote: post #8

Good refactoring respects the idioms of the language and the culture of the organisation. Change to new methodology is thoughtful and probably slow, except when a revolution happens but then, its still respectful to the new culture. Bad refactoring is elitist, "you won't understand this" commented and the owner walks with nobody left behind who understands it. That the examples deprecated FP and preferred an idiom na…

>Good refactoring respects the idioms of the language and the culture of the organisation. Change to new methodology is thoughtful and probably slow, except when a revolution happens but then, its still respectful to the new culture.

Burkean programming lol

Re: Good refactoring vs. bad refactoring

#147

Post by CRConrad »

kagevf wrote: post #116
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, which is better - for or map - depends on context. map typically is functional and allocates memory, for does not. But for is more likely to have side-effects. Which trade-offs matter depends on the larger context of the surrounding code.

> map typically is functional and allocates memory, for does not. But for is more likely to have side-effects.

If / when memory is low, allocating memory can itself be a side-effect...

Re: Good refactoring vs. bad refactoring

#148

Post by CRConrad »

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

Earlier quoted context omitted.

Making analogies like this doesn't prove anything, they're just suggestive. All I'm getting out of this is that you think for loops are old-fashioned.

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

> Functional code is more readable.

All I get out of that is that you like functional code.

Re: Good refactoring vs. bad refactoring

#149

Post by CRConrad »

The_Colonel wrote: post #23
vasco wrote: post #20

Earlier quoted context omitted.

Your second part is how I think and how I think most people think. That's exactly what I meant.

So when you arrange the visit with your friend two weeks in advance, you first think about sitting in the car, driving out of the garage, getting on the highway, turning on the radio, parking the car, ringing the bell and this other myriad of actions, and the actual talking with the friend is just one of the actions, with no prominence over the others? I certainly don't think like that. My main goal is to visit a fri…

No, we just think "I'll get in the car and drive to the hospital, talk to my sick friend, and then drive home by way of the petrol station". Higher-level, but definitely still procedural / imperative. (Then while we're driving we'll think "I'll turn left here" or "I'd better overtake that lorry", or whatever. But we don't need to plan all that beforehand; we do stepwise refinement on-the-fly.)

I think most people think more or less like that, and that it is not "a sign of autism".

Re: Good refactoring vs. bad refactoring

#150

Post by CRConrad »

nailer wrote: post #10

Oh god the ‘object oriented’ refactor. I wish everyone who had OO thrust upon them in the early 2000s received some explicit communication that what they were taught is essentially a hoax and bears no resemblance to Alan Kay’s original intention

"Object" and "orient" are ordinary English words; Alan Kay doesn't own either of them. He may have been the first to combine them as a single term, but he doesn't own that either. (Or, did he trademark it or anyything? I doubt it.) That another definition of it than his came to be the dominant one is just the way things are, not in any way "a hoax".
Post reply on HN