You need the problem space to be restricted to a manageable bunch of classes. If that’s not the case, split the problem until you get there.

Make sure you have 100% test coverage on this piece of code and that the tests are actually understandable and documenting the functionality well. You might find that there is unreachable code which should be deleted. Mutation testing may also help find code paths which are untested (and so edge cases you might not have considered).

Until that is true, write tests and/or refactor existing ones. At this point you may find a ton of new bugs there. Better find this now than later and then wonder whether your own changes introduced them. Your new failing tests will document the presence of those bugs.

By now you should have full documentation of what the code is supposed to do via tests. This will be tremendously helpful in understanding the code.

Then go public method by public method, line by line, renaming variables, extracting private methods etc. Your basic run-of-the-mill refactoring of classes, until you fully understand what’s going on in the production code.

For every small refactor, run the tests and commit if they pass. If they fail, you only have a small amount of uncommitted code which you know is the culprit.

Finally, fix any bugs you documented in the test writing stage.

At this point you can add any new functionality to the code.