I forgot to mention this: I would begin with functional/integration tests first, unit tests later or at least I would de-prioritize them.
If there are no tests you should start testing for features, not necessarily for small units.
Play with the actual app, understand how it works, maybe sprinkle it with some log.debug statements if you're unsure, then write a test where you "excercise" a behavior and expect an output. If you do this a few times you setup a battery of tests tied to specific functionalities.
After that you can refactor with a little safety net in the form of those tests that can also act as a documentation for posterity.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I love refactoring code, mine or other people's. It helps me learn something new and figuring out how it actually works or how it can be improved.
Just don't get carried away into refactoring everything.
Choose an inital goal, maybe a small one. Yeah this or that module could be better but:
I agree with @kuhnerdm , you should write a few tests of your own, especially if there's neither documentation nor comments.
Keep in mind that refactoring can introduce bugs, especially if there are no tests :D
Hey, @rhymes thanks. Now, I am clear that tests are key things to start with as mentioned by many.
I forgot to mention this: I would begin with functional/integration tests first, unit tests later or at least I would de-prioritize them.
If there are no tests you should start testing for features, not necessarily for small units.
Play with the actual app, understand how it works, maybe sprinkle it with some
log.debugstatements if you're unsure, then write a test where you "excercise" a behavior and expect an output. If you do this a few times you setup a battery of tests tied to specific functionalities.After that you can refactor with a little safety net in the form of those tests that can also act as a documentation for posterity.