in reply to Working with old code

You are not alone. Throughout my business life I have worked with old code written by someone else (To be honest, I've hardly ever written new code).

As others have recommended, a good set of tests is absolutely necessary for such a refactoring. Old code is often battle hardened: It covers some edge cases in ways which are hard to understand because back then it seemed to be the easiest way to fix a long forgotten bug. Probably you'll need to write a lot of tests before even writing the first line of your new code.

I also recommend to refactor only when you have a concrete goal in mind: Some new feature, better security, whatever. Don't write the feature right now, but think about how you would like to integrate the new feature, if only the old code would allow it. Then refactor the relevant parts of the old code, still without changing its behavior - and only when you're done with that, add the new feature. Or, in other words: Don't refactor just for the fun of refactoring. Subroutines with more than 100 lines aren't immoral.

The details depend on the ecosystem of the code:

So, to sum it up, my recommendation is: Don't focus on the code alone. Improve the ecosystem as well: Documentation, tests, tools. If the old code is still relevant (why else would you have to work with it?), then there are chances that you need to pass it to someone else in the future.