3 ms·
I've had to work with a big, slow legacy ball of spaghetti several times in my career. The original coders were long gone, but the code lived on. I always foun
by blisterpeanuts 11y ago
I've had to work with a big, slow legacy ball of spaghetti several times in my career. The original coders were long gone, but the code lived on.
I always found the best approach was to get familiar with the code as quickly as possible: read it beginning to end. Then disrupt it with small changes to see what happens. Insert comments as needed. Refactor here and there to make it easier to understand, and rename functions and variables to more meaningful names as you come to understand them. I've found it useful at times to print out all the code and lay it out on a table.
Eventually you become the master of the code. It's painful and you may have to put in some long days, but it's worth it.
Of course, the whole time you're working on this project, you might be thinking of ways to replace it with something more modern, performant, and maintainable.
- natch 11y agoThe book Working With Legacy Code is fantastic and suggests something a lot like the approach you've outlined. I leaned on it as a source of ideas when I once took over a fairly challenging old project. The other thing it recommends is adding tests but really all the parts you talked about are as important if not more so. To OP, I'm repeating some of what blisterpeanuts said but it's worth emphasizing that refactoring, even with very small changes, will make a huge difference over time. It gets you engaged with the code, helps you know it, and gives you small things to do when the big picture is too overwhelming. Also as he said, renaming variables as appropriate.. sounds minor, but this is huge, because you can make the names things that make sense and make the code more readable. The small changes you'll make will add up and the code will become easier to work with, and then the work will go faster.