Refactoring For Dummies
I recently re-read Martin Fowler’s classic text on Refactoring. There is no doubt that it’s a foundational book with many key ideas, but the main problem is that it’s just not written in an approachable way.
When he starts talking about “Divergent Change” and “Parallel Inheritance Hierarchies”, he just loses a large part of his audience along with breaking a cardinal rule of Strunk & White – No $10 words.
As Steve Jobs has told us, people don’t read anymore. They scan. And in my opinion Fowler’s classic textbook on Refactoring is just not written for scanning. It’s written to be studied like a college text (which may explain why it’s only in hardback and has a built-in bookmark).
On the other end of the spectrum, we have the Dummies and Head First books. They are fun and strive to ensure that you can scan and remember what you read rather than just transmit a ton of dense information. They avoid the wall of text.
After reading Refactoring for roughly the third time and finally remembering a quarter of it, I’d like to present to you my simplified summary – “Refactoring for Dummies” if you will:
1. Refactoring is Your Civic Duty
In order to write maintainable software, you must refactor. It’s easy to overlook quality in the the rush to add new features, but let me ask you — Do you write perfect code the first time? If you answered “yes” you’re lying so take the test again.
If you answered “no” then you need to refactor. It’s your civic duty and a hallmark of what it means to write software as a professional. Not only that but for any code base that has a long lifespan, the costs of refactoring to more maintainable code will pay for themselves in the long run.
2. Tests Allow You To Refactor
The goal of refactoring is to improve the code quality without changing the behavior. So the question becomes, how do you know all the expected behavior of your code and how do you know that you didn’t break it?
For small code bases, you can probably keep it all in your head, but for large code bases the best way is to have tests that you can run. This will easily show you whether you have inadvertently broken something with all your fancy refactoring.
3. Duplicate Code is Evil
If you have code that is the same (or nearly the same), turn it into a method that both locations can use. For obvious reasons, this is a huge win for maintenance. Also, you get the added benefit of making the code clearer as long as you choose a method name that is specific. Instead of having an unnamed block of code, you name a named re-usable chunk with a descriptive name.
4. Smaller is Better
In the world of maintainability, smaller is often better. It’s easier to maintain many small (well-named) units rather than one large one. We learned that the hard way back in the monolithic vs. modular code battles.
So, when refactoring your code, you should strive to achieve the following:
- Smaller Methods: If you have to scroll through pages and pages of code to get to the end of a method, it’s doing too much and is too big.
- Less Parameters: Have you ever tried to call a method with 14 parameters? Not fun. The less parameters you have, the better. If you really need to pass a lot of parameters, consider bundling them into some kind of object.
- Smaller Classes: Does your class have 300 methods? Then It’s probably doing too much and does not accurately model one entity. Consider breaking it into smaller, more focused, classes.
- Smaller IF Blocks: Does your code have gigantic, deeply nested IF statements?Sad to say I have fallen victim to this one. The better solution is to either employ helper methods or guarded blocks. In other words, test the exception rather than the normal case and immediately return if it’s true.
I’m just scratching the surface of what Fowler covers in his book, but I think this is the bare essentials.
And for those of you stout-hearted enough to read Fowler cover-to-cover, I’m impressed! May I recommend War and Peace next?
