Rewriting 10-Year-Old Legacy Code in 3 Months
The project I was assigned to right after joining was a "service no one touches." The last commit was from three years ago, and the person who owned it had left the company long ago.
I spent the first two weeks just figuring out the structure, and the next two weeks guessing why it had been built this way. The conclusion was "because they were in a hurry back then." It wasn't that there was no documentation—the only thing recorded from the start was "this will at least keep it running."
From then on, I went in order. First, I wrote tests first. That alone was half the battle. By locking down the existing behavior, I could take it apart without fear. Second, I changed only one thing at a time. If you mix refactoring and feature additions, accidents are guaranteed. Third, I shared every change with the team. If only you know, it'll all get undone later.
As a result, the number of lines of code dropped by 40%, and deployment changed from manual scripts to CI. Honestly, none of it was technically difficult. What was difficult was getting agreement on "is it okay to do this?"
If you encounter legacy code at work, don't be intimidated—start by writing tests. That's the fastest way.
5 answers
I think the key part is "consensus on whether this is okay to do." Ultimately, technology is half about persuading people.
Writing tests first is so true. The scariest part of touching legacy code is asking, "Why was this written this way?"—and you end up wasting all your time just trying to figure that out.
If you cut it by 40% in three months, isn't that effectively a rewrite? Honestly, I'm curious—did you never have any outages during the refactor? The article emphasizes "one at a time," but it's a bit disappointing that it omits how you handled operational issues during those three months. Our team tried something at a similar scale, rolled back twice right after deployment, and gave up. I'd also appreciate it if you could tell us what the test coverage was like.