Assuming a best-case scenario where I have time to commit to refactoring, I actually understand what the code is doing, and there is at least some supporting code like tests, comments, docs, etc.
I'd write some test-cases if possible, to verify the current existing behavior of the code. If it isn't possible or easy to test, I'd try to refactor it so I could test it. If its still hard to test, it might be too far gone.
I'd do some no-risk refactoring, clean up comments, format, etc.
I'd be damn well sure I understand what the code is doing, with or without tests.
In the worst case, where I can't write tests, its extremely complicated and extremely critical, I'd try to do as little as possible to it to prevent any breakage down the line. I'd also keep the code in mind as a candidate as a refactor/re-write.
I believe if you can write tests for code, you can refactor it much easier, without worry. If you can't write tests for dirty/ugly code, then changing it is risky, and since not all code can be tested easily it might not be worth the risk and work, especially if the code works.
Assuming a best-case scenario where I have time to commit to refactoring, I actually understand what the code is doing, and there is at least some supporting code like tests, comments, docs, etc.
In the worst case, where I can't write tests, its extremely complicated and extremely critical, I'd try to do as little as possible to it to prevent any breakage down the line. I'd also keep the code in mind as a candidate as a refactor/re-write.
I believe if you can write tests for code, you can refactor it much easier, without worry. If you can't write tests for dirty/ugly code, then changing it is risky, and since not all code can be tested easily it might not be worth the risk and work, especially if the code works.
I feel sorry for putting you in an undesirable position. My apology for that, and thanks for your insight.