Refactoring JavaScript

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. 

Share