In my last post, I explained why incremental refactoring techniques will make you both more productive and relaxed.
As anything worth its salt, the path to full mastery is long and requires dedication. The good news is that you’ll start to feel the benefits long before you are a master.
The quickest thing that will get you up to speed is dedicated practice. Take some time to do some exercices outside of any ‘production’ code.
TDD Coding Katas
The most famous practice to learn TDD also works very well to learn refactoring. That shouldn’t be a surprise as incremental refactoring is an integral part of TDD.
There are many ways to do your first coding kata. You could find a coding dojo near you (ask meetup.com). Or you could find motivated colleagues to start one at your company … I wrote in more details about how to attend a coding dojo in this post.
You can also practice katas on your own. My friend Thomas Pierrain rehearses the same katas to discover deeper insights.
The goal of incremental refactoring is to keep the code production ready all the time. Smaller commits is one happy consequence of that.
You can stretch your refactoring muscles by doing coding katas and keeping the code compiling all the time. You’ll need to master your IDE and its automated refactoring. Most of all, it will shift your attention from the goal to the path !
I learned at SPA conference that we call this ‘Refactoring golf’. The name comes from Golf contests, popular in the Perl community. Their goal is to write the shortest program possible to do a specific goal. The goal of a Refactoring Golf is to go from code A to code B in the fewest transformations possible.
They are a few refactoring golf repos on Github, I tried one and found it fun ! Give it a try too !
Study some theory
Real mastery does not come by practice alone. Studying theory alongside practice yields deeper insights. Theory enables to put your practice into perspective and to find ways to improve it. It saves you from getting stuck in bad habits. It also saves you from having to rediscover everything by yourself.
Develop your design taste
In Taste for Makers Paul Graham explains why taste for is fundamental to programming. Taste is what allows you to judge if code is nice or bad in a few seconds. Taste is subjective, intuitive and fast, unlike rules which are objective but slower. Expert designers use taste to pinpoint issues and good points in code on the spot.
Within the fast TDD - Refactoring loop, taste is the tool of choice to drive the design. Guess what : we can all improve our design taste !
Code smells are the first things to read about to improve your design taste. Once you know them well enough, it will be possible to spot things that might need refactoring as you code.
Spotting problems is nice, but finding solutions is better ! Design Patterns are just that … There has been a lot of controversy around Design Patterns. If overusing them leads to bloated code, using them to fix strong smells makes a lot of sense. There is even a book about the subject :
Finally, there’s a third and most common way to improve our design taste. It’s to read code ! The more code we read, the better our brain becomes at picking small clues about what nice and what is not. It’s important to read clean code but also bad code. To read code in different languages. Code built on different frameworks.
So, read code at work, read code in books, read code in open source libraries, good code, legacy code …
Learn your refactorings
As with most topics in programming there is a reference book about refactoring. It’s Martin Fowlers’s Refactoring, improving the design of existing code. Everything is in there, smells, unit testing and a repository of refactoring walkthroughs.
The book is said to be a difficult read, but the content is worth gold. If you have the grit, give it a try ! At the end, you should understand how your IDE does automated refactoring. You should also be able to perform all the refactorings that your IDE does not provide by hand ! This will enlarge your refactoring toolbox, and help you to drive larger refactorings from A to B.
Develop a refactoring attitude
Practice makes perfect. Whatever our refactoring skill, there is something to learn by practicing more.
Make it a challenge
As you are coding, whenever you find a refactoring to do to your code, make it a challenge to perform it in baby steps. Try to keep the code compiling and the tests green as much as possible.
When things go wrong, revert instead of pushing forward. Stop and think, try to find a different path.
If you are pairing, challenge your pair to find a safer track.
This might delay you a bit at first, but you’ll also be able to submit many times per day. You’ll see that your refactoring muscles will grow fast. You should see clear progress in only 1 or 2 weeks.
Team up against long refactorings
If your team prioritizes a user story that will need some re-design, try to agree on a refactoring plan. The idea is to find a coarse grain path that will allow you to commit and deliver many times. This plan might also help you to share the work on the story.
Having to question and explain your assumptions will speed up your learning.
Refactoring is most useful with bad legacy code. Unfortunately, it also where it is the most difficult. Next week’s blog post will be about what we can do to learn how to refactor legacy code.
That was my second post in this mini-series about refactoring. First one was 7 Reasons Why Learning Refactoring Techniques Will Improve Your Life as a Software Engineer. The third and last is 10 things to know that will make you great at refactoring legacy code