[titzer]

> - If I change it unsuccessfully, it will break a core part of the system that people are paying for.

Every refactoring comes at risk of breaking something. So if you refactor this code often, you are risking an outage--the very thing you are trying to prevent!

As others have said, if it ain't broke, don't fix it.

It sounds to me like said shitty code got lucky in the tech debt casino. But great! Look at it, so you know how it works, but don't mess with it.

[denton-scratch]

> Every refactoring comes at risk of breaking something.

Refactoring is code transformations that don't affect functionality. If something broke, that's a failed refactoring.

[titzer]

Which you discover after deployment...same deal

[denton-scratch]

Manual refactoring is certainly risky. So it should be set about with automated tests, specifically to protect the refactored functionality.

But I think any legitimate refacvtoring can be carried out by automatic tools, with guarantees of unchanged functionality/semantics.

The number of refactorings possible for any piece of code is almost infinite; you can't just let some tool loose on your code to perform all possible refactorings. That's madness. You need a human to judge which refactorings are beneficial. But the actual transformation should be performed by a tool that knows the language, and can guarantee semantic equivalence.

And you still need tests. You can scrap them once the refactoring has been shown to have not changed the functionality.