Refactoring

familiarize yourself with common refactoring techniques, including: extracting functions, classes and variables; inlining functions and variables; combining functions into a class

Refactor code to make it maintainable and readable.

Consider using the apply first, study second approach with the learning tactics and resources below: implement one of the practices from the Apply It section first. If you get stuck, then use the book in the Reference section. The point is: the quicker you get to the “doing,” the better the learning. Make your learning active.

Apply It

There are several ways to learn and get better at refactoring:

1. Get feedback from another programmer.

As I mention in the Design section of the Pyramid, awareness can be a great teacher. So after you complete a program, ask another programmer to provide feedback, so you can become aware of what you need to do to write better code.

Tip: Focus the reviewer’s attention when asking for feedback. For example, maybe you want to get better at extracting functions. Tell the review that, so they can focus their time and attention on this one aspect of refactoring. Specifying what you want feedback on is useful for the reviewer (they know where to spend their time and attention), and for the reviewee (you’ll get higher-quality, focused feedback).

The feedback you get can bring awareness to the parts of your code that can be refactored. Then, apply your learnings to the program you wrote—and in future ones. The point is: do something with the feedback you receive.

Compile the refactoring suggestions you get from the feedback you get into a checklist. Then, once you’ve solved a problem, take a look at your checklist: Extract functions...check. Extract variables...check. Eventually these things will become muscle memory, but until then a checklist will help you make that a reality.

3. Study the code of others.

Throughout the Pyramid, I suggest studying the code of others for different reasons. Well, here’s another: study the code of others to get refactoring ideas.

Tip: I must stress the importance of studying the code of someone that you admire and want to emulate. So pick someone who’s better than you and can teach you something. Otherwise, you risk picking up poor habits.

Complete a problem, and then study the code of others who’ve solved the same problem. Then, compare your program to theirs. A simple side-by-side comparison can be illuminating: refactoring best practices will literally pop out at you, at least that’s been my experience.

Here’s what I mean. I distinctly recall the first Advent of Code problem I solved. After I completed the problem, I compared my solution to another programmer’s, and learned a ton. What stood out most was this programmer’s use of extracting functions, which made his solution clear and elegant. In contrast, all of my code lived in a single function. But—and this is the important point—by studying this programmer’s solution I was reminded of extracting functions and had a context to apply this refactoring principle to.

Tip: Solidify your insights: type a short summary of what you learned and observed from the code that you just studied. It’s one thing to make a mental note, and think: “yeah, I got this.” It’s something else entirely to pause for five minutes and summarize your learnings. Putting words around ideas helps to solidify the information.

LeetCode, Exercism, and Advent of Code are three platforms that offer plenty of problems to solve and solutions to study.

Reference

Reference the book Refactoring by Martin Fowler as needed. Or get a taste of Fowler’s refactoring ideas on his website. Here’s a suggestion for how to use this book: after you get feedback on your code, reference Fowler’s book on that specific topic.

This book is example heavy, which is a reason why it’s so useful. Fowler shows code before it’s refactored, which is helpful so you can start to spot opportunities to refactor. Then he walks you through each step of the refactoring process.