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

111–120 of 154 posts

Re: Good refactoring vs. bad refactoring

#111

Post by ncr100 »

charlie0 wrote: post #78

Agreed with everything except the following: >Remember, consistency in your codebase is key. If you need to introduce a new pattern, consider refactoring the entire codebase to use this new pattern, rather than creating one-off inconsistencies. It's often times not practical (or even allowed by management due to "time constraints") to refactor a pattern out of an entire codebase if it's large enough. New patterns can…

"Foolish Consistency is foolish." -me, wasting your reading attention

The cost / benefit needs to be calculated, whichever approach is chosen, at an Appropriate periodicity, which also needs to be considered.

Re: Good refactoring vs. bad refactoring

#112

Post by jholman »

_a_a_a_ wrote: post #109
riwsky wrote: post #106

Earlier quoted context omitted.

Sure, comprehensibility is the terminal goal—but size reduction is relevant because it’s an easily measured, decently predictive proxy for that. No, code-golfing 3 lines down to one doesn’t help, but the bigger size differences are always of the “composition over XYZ” variety that change the entire complexity class of how much code you need to write (like React letting people write O(states) rendering code instead of…

Size reduction usually follows but not necessarily. That is easily measured is an irrelevance. The claim that its a decently predictive proxy I can't buy at the moment, can you try justifying that? Some very terse code can be very hard to understand without (comprehensive) commenting eg. https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv... Maybe you're right. I've had a drink, I'll think over it in the mor…

If you don't care about performance, we can make that code a lot shorter.

  float Q_rsqrt(float number) {
    return 1 / sqrt(number);
  }
The "fast inverse square root" is absolutely 100% all about performance. For it to make sense to use as a counter-example, you need to show alternate code that still meets the contract (the contract being: be as fast as this code), that is longer, and clearer.

Re: Good refactoring vs. bad refactoring

#115

Post by darioush »

I agree with the sentiment of this article, more recently I have come to think the best refactoring is the one you don't undertake. Hoping to achieve consistency is a very high standard.

Often code structure matters much less than data flow and how it is piped. Since most codebases use a mixture of:

- global state or singletons, - configurations provided externally (config file, env var, cmd option, feature flag, etc.), that are then chopped up and passed around, - wrappers and shims, - mix of push and pull to get input/outputs to functions, - no consistency or code representation of assumptions about handling mutable state,

It may be better to build around existing code using ideas listed here than to try to refactor code to improve its structure: - open/closed principle = compose new code for new functionality (instead of modifying), - building loosely coupled modules (that interface via simple types and a consistent way of passing them) - enforcing an import order dependency via CI (no surprise cyclic dependencies months after an unrelated feature added some import that doesn't "belong")

The code's structure will be simple if the dataflow (input, outputs, state, and configuration) flows consistently through the codebase.

Re: Good refactoring vs. bad refactoring

#116

Post by kagevf »

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.

Re: Good refactoring vs. bad refactoring

#117

Post by gloosx »

Ad-post for yet another AI tool.

Refactoring is about moving existing code around, not introducing new code. Replacing localStorage methods with cacheManager is a fix/feature. Updating one part of the codebase to work completely differently from the rest is a fix/feature. Changing processUsers to a whole useless class is not considered refactoring, it is a fix/feature. A single page app for a SEO-focused site is NOT a bad idea since 2018. Most examples of "refactors" in the article are actual fixes and features which brought (bad), or not brought (good) new regressions into the software.

Re: Good refactoring vs. bad refactoring

#118

Post by sevnin »

nuancebydefault wrote: post #93
FooBarBizBazz wrote: post #67

Earlier quoted context omitted.

The metaphor, I think, is that your code is a mathematical function, and, to be even more specific and "toy example" about it, let's say it's a polynomial. If the old code was x^2 + x z + y x + y z then you notice that you can express the same polynomial as: (x + y)*(x + z) It's still the same polynomial, but you "separated concerns", turning it into a product of two simpler factors. Similar ideas apply to sets of tu…

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.

He said "I think" implying that he is not fully sure about the etymology. There is a history section on wikipedia for refactoring if you are interested.

Re: Good refactoring vs. bad refactoring

#119

Post by Y_Y »

_a_a_a_ wrote: post #84
Y_Y wrote: post #59

Earlier quoted context omitted.

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

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

Re: Good refactoring vs. bad refactoring

#120

Post by 8n4vidtmkvmk »

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…

This is why I always ask "Is this going to leave our code in a better or worse position if we abandon yhis half way through". If the answer is "worse" then don't start it. Not unless you can get the entire thing done in about a week. If it takes a quarter, the probability of reprioritization is way too high.
Post reply on HN