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