Refactoring gets really bad reviews, but from where I’m sitting as a hobby programmer in relative ignorance it seems like it should be easier, because you could potentially reuse a lot of code. Can someone break it down for me?
I’m thinking of a situation where the code is ugly but still legible here. I completely understand that actual reverse engineering is harder than coding on a blank slate.
Refactoring is good work. Rewriting is shallow fun.
Do the math.
Exception: perl is write-only code. Always rewrite.
this is a big ol’ “it depends”
if it’s a hobby project, then by all means rewrite it if you want to.
if it’s a commercial project of some kind - there’s a business that’s making money, and part of the business making money relies on this code working properly - then rewrites are almost always a bad idea.
read Things You Should Never Do, Part I, an almost 25-year-old blog post (man, that’s a weird sentence to write) about why giant rewrites in a commercial setting are a bad idea.
in general, people greatly underestimate how much work is involved in a rewrite. it feels like it should be simpler to start from a blank slate, and tell yourself you’re going to avoid all the mistakes that you hate with the existing codebase. maybe you’re writing it in a new language, or at least a newer dialect/version of the same language.
if the current codebase is a mess…how did it get that way? lack of engineering discipline? a “just make it work now, we can go back and tidy it up later” attitude towards accumulation of tech debt? if those same attitudes are present on the team doing the rewrite, you’re going to end up right back where you started after the rewrite is “done”.
the main things you need for refactoring to be successful is a) tests, and b) a plan.
the tests allow you to refactor with the confidence that if you break something, the tests will point it out for you. trying to refactor something that lacks tests is the worst place to be in, because you’ll want to add tests, and often adding tests requires refactoring the code to be more testable, placing you in a catch-22.
the plan allows you to make those refactoring changes gradually, over time, while still maintaining the system. in the context of a business that’s paying developers to do this work, the businesspeople tend to look poorly on an engineer coming to them and saying “we’re gonna spend the next year or two doing a big rewrite, so in the meantime you can’t ask us for any new features or bugfixes to the existing system. but once it’s done the new system will be really cool, trust me.”
successful refactoring is a Ship of Thesus - you can replace the entire thing, but you have to do it one component at a time.
Rereading this, I probably should have added a hedge - is it usually better to start from scratch. I do know that there’s exceptions to most rules, and this isn’t actually a practical problem I’m facing.
Thanks, this is kind of how I thought it should be. I just didn’t know if I was missing something, because people on the humour communities trash talk refactoring a lot.
Edit: Wow, Netscape… Sorry to say it, but that post isn’t much younger than me. I don’t even know a most of these examples. That being said, it was still a great read.
This is a good answer.
At my job, there was a desire to do a big rewrite of the system. It was a disaster. We spent like 8 months on this project where we delivered no value to customers. Then there was essentially a mutiny from the engineering team and we killed it.
We’ve since built on top of the original system and had, in the words of product leadership, “the most productive quarter in the history of the company”.
Now, why was it a disaster? The biggest reason was that people, especially people in leadership positions, did not understand the existing system very well. They would then make decisions based on falsehoods and mythology.
I’m almost always of the opinion that refactoring is better than a rewrite as long as the tech stack is supportable.
Everyone wants to rewrite stuff, because the old system is ‘needlessly complicated’. 90% of the time though, they end up finding it was complicated for a reason and it all ends up going back in. It does allow a system to be written with the full knowledge of its scope though, instead of an old system that has been repeatedly bodjed and expanded. Finally, if your old tech stack is unsupportable (not just uncool, unsupportable) then it can be the most feasible way. It will take ages though with no/little return until it’s all finished.
Refactoring is more difficult, as developers need to understand the existing codebase more to be able to safely upgrade it in situ. It does mean you can get continuous improvement through the process though as you update things bit by bit. You do need to test that each change doesn’t have unexpected impact though, and this can be difficult to do in badly written systems.
Most Devs hate working on other people’s code though, so prefer rewrites.
(Ran out of time to go into more detail)
How would you define “supportable”?
Most Devs hate working on other people’s code though, so prefer rewrites.
I now suspect this is basically where it’s coming from.
If your app uses silver light, VB6 or something like that where modern OSs, browsers etc just don’t support it and there is no upgrade path.
It could also be written in a language that is supported, but you just can’t hire Devs for.
Neither.
If you can code it in a week (1), start from scratch. You’ll have a working prototype in a month, then can decide whether it was worth the effort.
If it’s a larger codebase, start by splitting it into week-sized chunks (1), then try rewriting them one by one. Keep a good test coverage, linked to particular issues, and from time to time go over them to see what can be trimmed/deprecated.
Legible code should not require “reverse engineering”, there should be comments linking to issues, use cases, an architecture overview, and so on. If you’re lacking those, start there, no matter which path you pick.
(1) As a rule of thumb, starting from scratch you can expect a single person to write 1 clean line of code per minute on a good day. Keep those week-sized chunks between 1k and 10k lines, if you don’t want nasty surprises.
Legible code should not require “reverse engineering”, there should be comments linking to issues, use cases, an architecture overview, and so on. If you’re lacking those, start there, no matter which path you pick.
Yeah, I just added that bit in to keep away the “ACKTUALLY if it’s written UNIVAC III assembly you have to rewrite it” answers. Technically correct, but not what I need.
There’s no practical problem I’m immediately facing here, I just didn’t understand some of the opinions I was hearing and was curious. (All my hobby projects are either new software from scratch or adding features to existing code, right now)
Makes sense. As for the opinions, over time people end up cussing the same tools that were introduced to fix their previous problems, all tools can be misapplied 🤷
Refactoring is always easier.
Both methods really need acceptance tests before you can start, but with refactoring you at least have a working system for the duration of development.
From a professional perspective I’d say: don’t rewrite if you’re unsure about it. Rewrite if there’s a particular problem you need to solve and a rewrite is the only way to do it.
For example, you need to make major changes in the tech stack. Like switching from PHP to NodeJS. This is difficult to do without a complete rewrite.
Rewrite for the sake of rewrite is usually a waste of time, and it’s not certain that the code will turn out better in the end. You might end up with a similarly convoluted system either way. And the worst part is: now you have two systems to maintain at the same time.
Likewise, refactor if there’s a particular problem you want to solve. Don’t refactor just for the sake of refactoring. If you don’t have a clear goal, then you’re just scrambling the code around.
From a hobbyist perspective: do whatever you feel like. A complete rewrite can be a good learning experience.
Yes, do nothing is an option too, of course. When this has come up on Lemmy, it’s usually because there’s an identifiable issue.
Personally, I’m not really in the market to refactor anything right now, this isn’t a practical question. Honestly there’s plenty of FOSS that hasn’t been made the first time.
How long is a piece of string?
Rebuilding always takes a lot longer than you think. Refactoring always takes a lot longer than you think. I’ve been involved in failures and successes doing either.
In a way you’re right - someone else already mentioned the uncommon-but-plausible situation where the original edge cases are no longer possible and don’t need to be handled. Most engineering has “fat tails”, where the rare exceptions are actually pretty common. The thing is, “it depends” doesn’t convey very much. Do you have some examples you could add, maybe?
Unfortunately the work I’ve been involved in is all in a commercial setting and I don’t think it would behoove me to talk too much about it. One was a major replatforming of an enormous, global education platform. That succeeded but took 6 years, not 3. I’ve gone through major engine changes in various game studios; one of which was built from scratch, one which was kept up to date and had original GameCube code in it by the time we gave up on it and I’m in the middle of one right now, building a new platform for another education platform and refactoring a large VR platform. I wish I could detect a pattern of success - the only association I can find is with “patience”.
