Writing code is complicated – I don’t need to tell you that. But as you transition from a beginner into an intermediate developer, you need to become more organized and efficient. In this stage, I developed a process of refactoring code. Because, inherently, as your skills grow, so will your applications/websites.
What is Refactoring?
Refactoring essentially is the process
of extracting, optimizing or removing code that is no longer needed. There are a few different
“flavors” of refactoring, but for the purposes of this article, I’m only going to cover
one such flavor: the extract method.
Extract Method
The extract method is simple
in theory, but can be more difficult in practice when just starting to dive into refactoring.
Extract method is exactly how it sounds, extracting code into its own separate method. Here is a piece of
example code that represents a good candidate for extract method refactoring.
In the above function there are a few things going on.
– An ajax request is made to a given URL
– The results are processed into JSON
– A list element is created to store the results
– The results are looped over, and a list item is generated for each
What makes this function a
candidate for extract method refactoring is that it’s doing more than one thing. Good functions
should only have a single purpose.
There are at least two new functions
we will create in order to extract the logic out of the single function. First, we create a function to
handle the generation of the list and list items. Second, a function that simply calls the other functions
in the order required.
First, I created a new function
that requests and then waits for some data from the ajax function. Then it invokes
the generate ListFromData function to do something with that data.
Having the functions separated this
way increases readability, makes things easier to test, and positions the code to be updated and maintained in the future.
The Caveat to Refactoring
The caveat to refactoring is something
known as Premature Optimization. In my experience, this can be one of the biggest killers to productivity.
Essentially, it means is that you spend too much time attempting to refactor some code that doesn’t pay
off in the long run. This can be from trying to optimize a loop that doesn’t really have a negative performance
impact, or refactoring functions to be reusable that are only used once.
There are not really any
black and white answers to the question of what to refactor and when. It can all boil down
to organizational preference or the developer tastes who is conducting a code review. The only way you’re
going to find the balance is through iteration.
Next Steps
Code reviews and pair programming are
probably two of the most effective ways to learn the what’s, how’s and when’s to refactoring. If you are
in an organization with multiple developers, then you may already be doing this which is great!
If you do have multiple developers but
are not conducting code reviews, then you should take a serious
look at implementing these. They provide
invaluable feedback and can help both the reviewer and reviewee learn not just about
refactoring, but generally about development.
If you are working alone, there’s good
news and bad news. The good news is you have the freedom to exercise your own preferences. The bad news is
there’s no one to conduct proper code reviews. There are ways “around” this roadblock however, such as posting
your code for review on popular websites such as Reddit or StackOverflow.
Conclusion
When you are actively refactoring your
code, you not only set yourself up for success, but also anyone who comes after you. Companies should strive to
write maintainable code, but it’s a balance of knowing what to refactor and when that only comes from
experience. Generally, writing clean code saves money because it saves time.
