Daniel Irvine on building software
What refactoring isn't
4 October 2012
Let me just state this up front: changing code for the sake of change is not okay and should be forbidden by any decent software development process.
This happens frequently enough for it to be a problem. Developer Joe comes along and notices code that his teammate Developer Sue wrote, but unfortunately he has a problem with it. Not a problem as in, there’s an error in this code, but a problem as in this isn’t written in my style and I don’t understand it. The temptation is there for Bob to modify the code so that he understands it and it’s to his liking, so he goes along and does it. What’s worse, this is done under the guise of “refactoring”, which is an abuse of the term. Refactoring is changing code when it facilitates a new feature to be built on top of the changed code, not changing code without a functional purpose.
Often this change is just little things like breaking out methods, adding comments, pulling out local variables, changing the structure of loops or changing the scope of try/catch blocks. But any change, no matter how small, can introduce bugs. And that’s exactly why we shouldn’t do it.
This temptation to make this kind of change is great, and that’s because it’s the easy mental approach. The more difficult mental approach is to leave the code alone and study it until you understand it.
Leave that code alone! Seriously. If code has been released and is in production use, then all of the following apply:
- it has been tested (since it’s being used)
- it works to a reasonable level
- it may have been code reviewed