Hit with a Reality Check While Refactoring Legacy Code
I took on refactoring a service that's been running for 10 years without a single test, and honestly, the more I touch it, the more it feels like it's going off the rails.
If I fix one function, I don't know where something will blow up, so every deployment makes my heart race. But if I don't fix it, I can't add new features.
How do senior devs handle this kind of situation? Is the answer just to gradually tear it apart and fix it bit by bit?
5 answers
Agreed... Legacy code without tests is a real minefield lol
If a service has been running for 10 years, all kinds of edge cases and business rules are already baked into the code. If you try to rewrite it from scratch, it will fail 100% of the time. The approach I used was: 1) lay down characterization tests around the function you're about to touch first, 2) capture actual behavior with logs/metrics before and after deployment and use that as your baseline, and 3) never mix refactoring with feature changes. If you stick to this, you'll move slower, but you'll have far fewer heart-in-your-throat moments.