Refactoring code is a journey every developer must face at some point, whether you're looking at a tangle of your own making or grappling with someone else's mysterious creation. I find myself asking the same questions every time: Where do I begin? Why is this so hard? And WHAT IS THE POINT? As Iâve continued to write code, more and more people encourage me to refactor my code. So, I set out on a journey to answer these questions. Hereâs what I found:
What is refactoring code?
Before we talk about how to refactor code, letâs establish a definition. I would define refactoring very simply as the act of cleaning up code without changing its external behavior. Refactoring often involves:
Renaming variables to make them more descriptive.
Breaking large, unwieldy functions into smaller, more manageable ones.
Simplifying complex logic to improve readability (AKA the bane of my existence)
Removing redundant or unused code.
Itâs NOT about adding new features or fixing bugs. If thatâs the case - if the code already works, you might be asking yourself, why bother?
Why refactor? Whatâs the point?
There are a few key reasons to refactor code such as improved readability, easier maintenance, and enhanced performance (While refactoring isnât always about optimization, simplifying logic can sometimes lead to faster, more efficient code. RegardlessâŚ). We can sum all these reasons into one simple objective; making the code easier to work with in the long term. Itâs an investment where less is more; clean, succinct code today means fewer headaches tomorrow.
But I already knew all this! - well before I set out to write this blog post. Still, I could not find the motivation to refactor my code, even as I prepare to submit job applications. Not even the incentive of impressing potential employers could outweigh my frustration toward the task of refactoring. Then, during a class assessment, I was asked to debug the following code (I know I just said refactoring isnât about fixing bugs, and itâs not! bare with me, for just a moment):
Story Time :)
my_numbers = [1,2,3,4,5]
for number in my_numbers:
print(number)
if number % 2:
print("even")
else: print("odd")
I was told the above code should print even for even numbers and odd for odd numbers (easy enough). As written above, the code prints even odd even odd even, the opposite of whatâs expected. I knew that if number % 2 is the same as writing if number % 2 == True. Then, I quickly discovered % (the modulus operator) does not return divisionâs quotient; it instead outputs the remainder. Therefore, a remainder of 1 (AKA True) prints even, while a remainder of 0 (AKA False) prints odd. I begrudgingly proposed the following solution to debug the code:
if not number % 2:
Even though my solution returned the correct output, I didnât like how the code appeared to human readers- the way it is written isnât easy to understand. For those interested, a more readable solution is if number % 2 == 0:, but the specific solution isnât the point! In that moment, I was reminded:
Code itself is a compromiseâa delicate balance between human and machine languages. Computers, at their core, speak in binary: sequences of 0s and 1s that are precise but close to incomprehensible for the human brain. Meanwhile, humans think in rich, expressive languages that are far too complex for machines to understand. Code lives at the intersection, a beautiful dance along the line dividing these two worlds.
Refactoring is the practice of perfecting that danceâmaking the steps smoother, more graceful, and easier for everyone (humans and machines) to follow. I realized refactoring code is important for all the obvious reasons; PLUS, it helps me more deeply and intimately understand the machines Iâm working with, ultimately, allowing me to work in more effective and meaningful ways.
Finally, when should you refactor code?
As much as Iâve sold the value of refactoring code, I cannot deny refactoring code is A LOT of effort. And I donât think itâs always worth the effortâŚ
If you ask google, chatGPT, or whatever your search engine of choice âwhen is it important to my refactor my code?â Youâll receive a response along the lines of âIf your code is about to handle more users, data, or functionality, refactoring can lay a solid foundation for future growth.â Thatâs a start but a bit too general to be of much help.
In my first blog post, Coding as an Art, I demonstrate how the same task is accomplished with 3 different blocks of code and then, discuss why each method might be interesting and valuable to potential employers. This is to say what you do with your code depends on the context youâre working in; primarily, what your team or employer values. Get on the same page as your collaborators. Communicate - do not invest time in something that will not pay off. Watch and listen. How do people work (or struggle to work) with your code? Even better, actively solicit that feedback. If you have a supervisor, and youâre struggling to refactor, ask if refactoring is a current priority. When youâre working collaboratively, you have plenty of factors and resources to determine when to refactor.
If you are coding all on your lonesome, you can simply ask yourself, âdoes my code look like a Choose Your Own Adventure novel on steroids?â If yes, refactoring can help. Ultimately, the choice is yours. Just remember: Refactoring makes your life easier in the long run.