Quite often, when working with legacy code, there is a tremendous abhorrence to change. Usually this does have good reasoning behind it. If a system has been working for x number of years, you don’t want to just come in and starting changing things without cause. You will constantly come across bits of code that nobody remembers quite what the bug was that this bit of code was fixing. Or they may not even know what business feature this bit of code might tie back to.
What do you do when you run across code like this, possibly when working on some unrelated issue, and you are sure the bit of code you found is wrong, or could be better/cleaner/faster in some way? Do you go out and test and find out what the code really does and make the change, covering yourself with unit tests, and any other kinds of tests that may exist on the system? Or do you just back away slowly?
I don’t really think there is a single answer to the question of what to do when you stumble across code like that. Sometimes it is best to go fix it. Sometimes it is best just to leave it alone. A lot of that call depends on how critical the business functionality the code ties to is. If the thing isn’t used very much, while that may mean there is little business risk to changing it, that also means there is little value to changing it as well. The reverse is true for code that is exercised all the time; the risk to change it may be high, but the benefits you get from that change may also be very high. These are all trade-offs that need to be made, all within the few minutes you are thinking about making the code change or not.
Originally Posted on my Blogger site July of 2017