Anyone Else Work at a Company Where Legacy Code Has Zero Documentation?
It's been two weeks since I took over, and looking at the commit log, the most recent one is from four years ago. Forget comments—even the function names are things like a, b, temp, so reading it gave me a harsh reality check.
The only silver lining is that there are a few tests, but even then, no one knows why they were written that way.
The senior devs say, "It runs, so don't touch it," and I don't know whether I should refactor it or just get used to it.
5 answers
Not touching it is the right answer. Seriously. Last year I said, "I'll clean this up a bit," started messing with it, and a side effect blew up the payment logic, so I ended up going into the office on the weekend. If you have tests, use them as a shield and go little by little. Don't try to rip everything out and rewrite it all at once—start by adding comments to each function you understand, one by one. Just that alone will make handover much easier six months later.
lol I really relate to a, b, temp. At my company right now, the function names are 'func1', 'func2', 'func_final', 'func_final_real'. I was curious what comes after final_real, so I dug around, and there wasn't anything
Got a source? Depending on exactly what percentage "there's a bit of test code" refers to, it's a completely different story.
Well, that's a bit... If the commit log is from four years ago, that means nobody's touched it since then. If you get greedy about refactoring and it goes wrong, you'll be the one blamed in no time. If the company won't give you time to refactor, just adapting is the right move.
There's a reason seniors say, "Don't touch it." Most of the time, it's because that code happens to satisfy some business rule. If you clean it up without knowing that, you'll cause an incident. But that doesn't mean leave it alone forever—start by increasing test coverage. Refactoring is a conversation for later.