Refactoring for Non-Programmers
If you work with computer programmers in your day job, you’ve likely heard them talk about “refactoring” code. In this short article I explain why and when refactoring is useful, and provide an analogy to help you understand the process.
Refactoring is the process of restructuring existing computer code without altering its external behavior or the results it produces. The word comes from mathematics, where factorization means “taking a composite number apart into numbers that multiply together to get the original number” (Simple English Wikipedia).
Refactoring is never necessary for code that will never be read by a human again. Refactoring is never necessary for code that will never change. However, refactoring can make code significantly easier to change.
To understand refactoring code without understanding code, consider this number:
1,051,200
This represents the amount of time for which my car registration is good in the state of Missouri. (Please resist the urge to look up Missouri law, pull out a calculator, or do mental math until the end of the article.) If this number was part of the code for a piece of software used by the Missouri Department of Revenue, this may be sufficient as the time is literally written into law.
However, if the laws were updated and I had to change this number to represent a new registration interval of 3 years, things get complicated. Now I need to use a new number, but that original number is completely unclear without both knowing what the old law said about the registration interval in normal English and doing some math to figure out what unit of time was used. In fact, if you did not have access to the current version of the law, you'd have a hard time deriving what the number is even supposed to mean.
Imagine, instead, that the number was factored into the numbers that multiply to it:
16 × 20 × 15 × 219
Nope, that’s no clearer than before. These numbers don’t seem to relate to time at all. While this factorization is mathematically correct, it’s not helpful for understanding the meaning behind the number. Making changes based on new requirements is no easier than before. Not all refactoring provides value.
Let’s update how this number is factored--let’s refactor it:
2 × 2 × 2 × 2 × 2 × 2 × 3 × 3 × 5 × 5 × 73
This is the prime factorization of 1,051,200. Mathematically pure, perhaps, but no more useful for understanding the amount of time it represents. There are many ways you can refactor a number. There are, in fact, infinite ways you can refactor a codebase. But only some of those factorizations are informative to the reader and, therefore, useful.
Let’s refactor to a form that would be useful to fans of musical theater, but not to everybody:
2 × 525,600
Some readers, especially fans of hit musical Rent, will have gotten value from this refactor. Those people, which might just include you, now understand how we got to this number in the first place, what the old registration interval was, and exactly what we'd need to change in order to comply with the new law.
For people who aren’t as much into Broadway shows, here is yet another refactor:
2 × 365 × 24 × 60
Hopefully now everybody with a basic understanding of calendars and clocks knows what this number represents, and has represented the whole time: two years (in minutes). All of these factorizations have represented the same time interval, and all of them are correct. They will all continue to work forever as-is. It’s only when you need to read and understand what’s there, something necessary for changing it, that refactoring matters. But refactoring can be the difference between looking on in confusion, and simply making a change quickly and easily.
Refactoring code is like refactoring this number: both the original version and the new version do the same thing, but the refactored one is hopefully easier to understand, reason about, and change. It’s possible to invest effort into refactoring and end up no better off than before, or to make it easier to change only for certain people. But with the right refactoring, code can be made to respond to change much more quickly and easily, paying off over time.