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