{"id":263,"date":"2014-11-28T08:10:50","date_gmt":"2014-11-28T08:10:50","guid":{"rendered":"http:\/\/localhost:8000\/?p=263"},"modified":"2025-09-07T13:47:22","modified_gmt":"2025-09-07T13:47:22","slug":"some-thoughts-on-refactoring","status":"publish","type":"post","link":"https:\/\/blog.gwadej.org\/programmer-musings\/2014\/11\/some-thoughts-on-refactoring\/","title":{"rendered":"Some Thoughts on Refactoring"},"content":{"rendered":"

I recently heard an interview<\/a> with Martin Fowler<\/a> on the Ruby Rogues podcast<\/a>. He pointed out a few things about the process of refactoring that I haven’t thought of in a while. Based on that interview and what I’ve read and learned elsewhere about refactoring in the past few years, I decided there are a few points worth making:<\/p>\n

Don’t Change External Behavior<\/h2>\n

By definition, refactoring improves the design of the code without changing externally observable behavior. If you change the behavior, it’s not a refactor. It’s a bug fix, or a restructure, or a redesign, or a re-architecture. Too many people use the term refactor to mean “I futzed around in the code for a while, but didn’t fix any bugs or implement any features.” That is not the same thing as refactoring.<\/p>\n

When you decide some code needs to be refactored, remember that you don’t want anything outside the code you are changing to be able to see any difference. This is part of the reason why unit tests are so important to refactoring. Without good unit tests, how are you going to know if anything has changed?<\/p>\n

Most Refactoring is Small<\/h2>\n

In the interview above, Martin Fowler explicitly stated that small refactorings are good. If you look at the definitions in the Refactoring book, you’ll notice how small each change really is. You might wonder how any change could make a difference. Experience among a large number of programmers has shown that small changes can incrementally improve the code. It’s slower than a big bang<\/em> rewrite, but it’s also much safer. Since each change is small, the risk of a major failure is also small.<\/p>\n

Another advantage of small refactoring that many don’t notice is that each successful<\/em> refactor improves your understanding of the code. More understanding leads to better changes. It’s reasonable to suppose that a series of changes based on increasing knowledge can result in better code.<\/p>\n

When a Refactor Breaks<\/h2>\n

In the same interview, Martin Fowler also made a point that I don’t believe I’ve ever heard before. If you refactor some code and it breaks the tests, don’t debug your refactoring. Throw it away, instead.<\/p>\n

If your refactoring changes are small, it won’t cost you much time to throw it away. More importantly, if you throw away the change and try again, the time you spend on the change is well-defined and limited. On the other hand, we all know that debugging can be an unbounded, hard-to-estimate time-sink.<\/p>\n

If you broke code with a refactor, that probably means at least one of the following:<\/p>\n