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

Refactor vs. Rewrite

remesh.blog

Post reply on HN
Print view View original

81–90 of 123 posts

Re: Refactor vs. Rewrite

#81

Post by emerongi »

fabian2k wrote: post #75

I found the move away from GraphQL again interesting, maybe because it supports some of my concerns about it. I never looked in detail into GraphQL, but just from the general principles I understand I found it rather scary to decide to use it. It's a big complicated thing directly between the data and the frontend. If anything goes wrong there, now I have to debug a much more complex piece of software than if I use a…

> it could be easy to create bad queries, and hard to fix performance issues

You can do complexity analysis of the query before you run it and deny requests that have complexity above a certain value. Some graphQL libraries provide this out of the box. Of course it won't eliminate all possibilities of bad queries, but at least most of them.

For me GraphQL simplifies life quite a bit. We have an internal library that plugs a lot of things in automatically but leaves full customizability options, which makes it quite convenient to build APIs. On the front-end there are very useful libraries that again make life simpler. In short: the biggest benefit is that I have more time to spend on things that actually matter, instead of inventing my own protocol that in the end is just going to be a worse graphQL.

Re: Refactor vs. Rewrite

#82

Post by chosenbreed37 »

cientifico wrote: post #64

In my experience, refactor vs rewrite is the wrong approach. Knowledge of the business must be maintained. If knowledge is on the team because the company is stable, rewrite. 37 signals is a clear example of this. If the knowledge is in the code, because multiple people or teams worked on the code base over the past few years, refactor. A rewrite will be the recipe for disaster. I never found an exception to this rul…

Great heuristic!

Re: Refactor vs. Rewrite

#83

Post by Chris_Newton »

jillesvangurp wrote: post #61
Chris_Newton wrote: post #56

Earlier quoted context omitted.

More expressive type systems might make refactoring safer , but they don’t necessarily make it easier . The former happens because it’s harder to change something encoded in the types accidentally. For the latter, it should be easier to change something encoded in the types deliberately, but often the opposite is true.

Having a type system enables zero risk automated refactorings, even complex ones and make them a no brainer. Not having that builds a reluctance to do even simple refactorings. A good example is the simplest possible refactoring: renaming things. I was doing this in pycharm on a simple python project the other day and it proposed modifying just about all dependencies on the classpath because it couldn't tell apart th…

It seems to me that what you’re talking about there has more to do with having clear rules in the language for scope and modularity than to do with the type system.

Re: Refactor vs. Rewrite

#84

Post by logicchains »

megameter wrote: post #2

IME whether you rewrite or refactor, the lesson is the same: You have to grind your way into the good architecture. It doesn't become good because the code is fresh, but because you have battle scars to show. And a success story in that case comes from having a complete learning loop. In a lot of orgs the learning itself is argued against for one reason or another - development proceeds with as little feedback on qua…

>IME whether you rewrite or refactor, the lesson is the same: You have to grind your way into the good architecture.

I think that only applies to things nobody on the team's built before. From my domain, HFT, if we hire a senior dev who's built blazing-fast futures arbitrage systems working for other companies, chances are if he rewrote our system it'd have a very nice architecture from the get-go, because he's already solved a similar problem multiple times before (and learned from the mistakes in those architectures).

Re: Refactor vs. Rewrite

#85

Post by Chris_Newton »

zo1 wrote: post #60
Ericson2314 wrote: post #42

I think everyone is missing the big point here: they current implementation was in an untyped language and so refactoring was just to hard. Use languages with good type systems and then refactoring is easy, and always the correct technical choice. Let me say that again, the killer app of type systems is that no mistake can "total" the code.

The lack of static typing does not make refactoring incredibly hard or difficult. In fact, I would argue it's even easier due to the way dynamically-typed languages pass around data. Really, as long as you follow some basic rules and don't propagate complexity into your system too-much, refactoring is a breeze. When I do it, the types are inconsequential almost. The things I do worry about when refactoring is develop…

Any halfway decent static type system would capture that nullability and prevent accidentally using a null value without checking, so you seem to have slightly undermined your own argument here.

Re: Refactor vs. Rewrite

#86

Post by code-faster »

Rewriting has a concave payoff. It requires high levels of certainty to be valuable. The bigger the rewrite, the more likely you're less certain than you think.

Refactoring is the same as rewriting, just on a smaller scale, which increases certainty.

Joel's advice assumes you will overestimate your certainty.

Re: Refactor vs. Rewrite

#87

Post by Someone »

logicchains wrote: post #84
megameter wrote: post #2

IME whether you rewrite or refactor, the lesson is the same: You have to grind your way into the good architecture. It doesn't become good because the code is fresh, but because you have battle scars to show. And a success story in that case comes from having a complete learning loop. In a lot of orgs the learning itself is argued against for one reason or another - development proceeds with as little feedback on qua…

>IME whether you rewrite or refactor, the lesson is the same: You have to grind your way into the good architecture. I think that only applies to things nobody on the team's built before. From my domain, HFT, if we hire a senior dev who's built blazing-fast futures arbitrage systems working for other companies, chances are if he rewrote our system it'd have a very nice architecture from the get-go, because he's alrea…

And then, that senior dev will pick a newer, better CPU, on-device bus, network topology, or your setup simply has a different scale, and hard-learned heuristic “don’t use more than x foo’s for y” or “the network is the bottleneck; use huge machines” become obsolete, and your dev will get some new battle scars.

I guess that will happen in HFT all the time, as you don’t want that blazing-fast setup, you want something even faster.

Re: Refactor vs. Rewrite

#88

Post by sys_64738 »

Chris_Newton wrote: post #43
sys_64738 wrote: post #5

When a developer says "I am going to rewrite ..." you have to question why? If you were not doing this "rewrite" then what else would you be doing? Refactor is usually a term used to minimally modify legacy code to allow new functionality to be added. Rewriting implies rewriting legacy code (regressions) and wasting time. If a developer says "it's the only way" then you need to be sure you can trust their judgement.

Rewriting implies rewriting legacy code (regressions) and wasting time. This isn’t necessarily true. A few years ago, we rewrote a large part of a web-based UI. The original implementation was a Java applet, a reasonable choice for an interactive diagram at the time it was first written. However, over time the applet had become a liability because browsers were planning to drop support, and in the meantime some usefu…

This is definitely an interesting case where your product suffers through external factors. Things like languages being EOL'd (python), technology becomes obsolete (like you mention here), vendor forcing change through API and security change through OS upgrade (iOS), and security CVE issues. These all cause sustaining to be done to older code in unexpected ways.

Re: Refactor vs. Rewrite

#89

Post by satyrnein »

Cthulhu_ wrote: post #68

I'm in the middle of a rewrite, but because my employer also wants me to do work on the existing application, I end up doing a lot of refactoring as well - if only for my own sanity and to help me understand the existing code. We're talking an only 8 year old (continuously developed during that time) app built in PHP and JS, but by someone who never bothered to learn web development proper. Resulting in a lot of copy…

If it hits the same database, build the new features in the new stack, and launch them. Users should click from the old to the new without even realizing. You have to figure out some details like sharing sessions, but this way avoids adding onto the old application. Otherwise you'll never catch up.

Re: Refactor vs. Rewrite

#90

Post by dep_b »

I hear more often things like "oh I don't have experience with X, so let's not use it". I mean programming languages are easy, frameworks are hard. Like learning how to use Django (which is pretty easy as far as frameworks go) to me seems harder than using React (assuming I know that already) with TypeScript instead of JavaScript. I would probably be really happy to use TypeScript instead.

If Elixir was a really bad match because it was hard to use the required libraries, OK I can understand that.

Post reply on HN