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