Keep hearing all these good things about refactoring but don't know where to start?
Here are seven cases where refactoring can help.
Case 1: When you need to make a change but it's difficult to do so.
for each desired change, make the change easy (warning: this may be hard), then make the easy change
— Kent Beck (@KentBeck) September 25, 2012
Instead of trying to make a difficult change, first, refactor the code so you can make the change easily. Then make the easy change.
Case 2: When you need to understand a piece of code.
When trying to understand a piece of unfamiliar code, play around with the code first. If some parts of it require efforts to understand, try to refactor the code to make it more understandable. The refactored code should reflect your understanding. Rerun the tests after each refactoring to make sure your understanding is correct.
Using refactoring as a way to understand a piece of code has two benefits:
- It helps you gain a deeper understanding of the design of the code and the problem the code is trying to solve. It's like "wiping the dirt off a window so you can see beyond.[1]"
- It saves time for the next person who comes after you.
Case 3: Three strikes and you refactor.
- The first time you do something, you just do it.
- The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway.
- The third time you do something similar, you refactor.
Case 4: When you try to debug or fix a bug.
Similar to case 2, you need to understand the code in order to debug it.
Case 5: When you do code reviews.
Similar to case 2, understand the code is one of the first steps of doing code reviews.
Case 6: When you just implemented a feature.
After you implemented a feature, take a step back and think if there's any way to improve your code before merging it into the production branch.
Case 7: When you feel stressed or tired from reading too many messy codes.
Like computers have RAM, we, human, have working memories. According to MedicineNet, working memory
"is a system for temporarily storing and managing the information required to carry out complex cognitive tasks such as learning, reasoning, and comprehension."
As a complex cognitive task, programming utilizes working memories. Unfortunately, each time we encounter a piece of messy code, as much as we want to ignore it, we can't help but add it to our working memories.
We say to ourselves: "uh, this is ugly, but I don't have time for it now. I need to move on with my current task, but hopefully, I can come back and clean it up later."
As time goes by, our working memories are filled with thoughts about messy code. Working at a messy office is rarely productive. Similarly, programming, which essentially is about learning and reasoning, when our heads are filled with thoughts about messy code can rarely be effective.
We need to clean and organize the office to make it pleasant again. Similarly, we can use refactoring, or Therapeutic Refactoring if you may, to clean up our working memories so we can return as happy and productive programmers.
Now you know when to refactor, next step is to learn about how to identify places in codes that need refactoring. Check out the Code Smell Cheat Sheet or download a pdf copy to learn about that.
Download the Code Smell Cheat Sheet
Sign up and get my Code Smell Cheat Sheet PDF and weekly articles about Software Design and Rails.
[1] Quoted from Refactoring
I know the idea but it turns out there is a rule for good timing on refactoring: “Three Strikes And You Refactor” #TIL
Yeah, “Three Strikes And You Refactor” is easy to follow and pretty practical as well.