Why and When should I refactor?

I recently bought the second edition of Refactoring by Martin Fowler, I like it a lot.

Last year I did a talk about refactoring with some thoughts I had: use ubiquitous language from Domain Driven Design to write code; apply visual design principles to identify code smells to start; and lastly refactor often.

I thought it is a good time to review the book and summarize what I learned in the past few months about refactoring.

The purpose of building systems is to continue playing the game. True long term thinking is goalless thinking. It is not about one single accomplishment, it is about a cycle of endless refinement and continuous improvement. It is your commitment to the process that will determine your progress.

- James Clear, “Atomic Habits”

What is Refactoring?

I find that refactoring becomes a loose concept term, similar as changing code for a better structure, where we miss some very important characteristics of it: it does not alter the external behaviors, and thus it needs to be done in a systematical disciplined way.

Refactoring is the process of changing a software system in a way that does not alter the external behavior of the code yet improves its internal structure.

- Martin Fowler, “Refactoring: Improving the Design of Existing Code”

Martin did a talk recently at Etsy Code as Craft Speaker Series, where he said: “Refactoring is a series of small changes that each change is so small that they are not worth doing it, but doing a whole bunch of them you are going to make a big change. ” This is also what DHH retweeted: small changes and programming habits.

So I think refactoring is a systematic and disciplined approach to change the internal structure of the code without changing the external behavior, such that “it makes the change easier.” Doing it often helps us to create good programming habits to write cleaner code and can continuously improve.

Why Refactoring?

In Martin’s book, there is a section on “Why should we refactor?” in Chapter 2. It talks about perspectives that refactoring improves the design of software; refactoring makes software easier to understand; refactoring helps me find bugs; and refactoring helps me program faster.

What resonates me most is that refactoring makes software easier to understand. As the software engineer who spent the past 8 years on legacy code bases, I spent more time reading and modifying the existing code than developing new code. I advocate that we should be more compassionate in coding to make our future self and others’ life easier. Making code easier to understand will save countless hours of future maintainers. My colleague and friend at work shared this article coding with empathy the other day. It reminds me of Sarah Mei’s talk Livable Code: The important part of software is not the code and the important part of software is not the people. It is code and people. Software engineering is working with other humans through code.

Making software easier to understand has multiple benefits: it makes the path to evolve a better design more visible; it accumulates domain knowledge as the code itself is the documentation; it removes accidental complications thus will improve our estimation of adding a new feature.

When to Refactor?

To avoid digging your own grave, refactoring must be done systematically.

In the book there is also a section about “When should we Refactor?”

From my experience working on product teams, the best strategy to use to do a “big” refactoring is “to refactor just before I need to add a new feature to the code base” and “make the change easier and then make the easy change.”

Take every opportunity, such as when investigating a production issue, fixing a bug, writing a design documentation etc., to do small “unworthy” refactoring changes to make the code easier to understand, such as renaming, extract methods, formatting, and align code so that it is easier to scan.

Before we change any code structures, make sure we have tests in place. If not, we need to start with characterization tests to capture the existing system behavior. Learn the systematic steps of refactoring outlined in the book so that we are able to make small changes every time instead of burying down in the rabbit hole.

Refactoring is good learning experience to understand the system better and end up making the system easier to understand. When we don’t understand our code, it is an invitation to do some refactoring.

--

--

--

Inspired and Inspiring. @bonniepan02 on Twitter.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Type erasure in swift

Do you really know what your cloud apps are costing you?

Custom Sections in WooCommerce Checkout Field Editor

[Live Now] HostGator Black Friday 2017 Coupon — 80% Off

Flutter Starter Kit (MoonLight)

[Installation Part 1] Visualizing ClickHouse Data with Apache Superset

Don’t Write Perfect Code

More than bug-finding — My Test Code Camp 2.0 Experience

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Bonnie Pan

Bonnie Pan

Inspired and Inspiring. @bonniepan02 on Twitter.

More from Medium

Spend your time in Code Reviews, not in writing Tests

MessageConverterBeans Or: How I learned to stop converting manually and trust in Spring

Need only 3 things to grow and get better at your ‘Software Engineering’ career from “South Asia”…

The Steps in making a Software