How to refactor your code? A guide to frontend refactoring

Are you planning to refactor your frontend code, maybe the entire frontend or just some feature? Don’t know where to start or how to make it more readable? Or you just want to know the best practices for having a more maintainable code? Well, this article is for you then. I’ll be covering what to do first and what to do last when you want to refactor your code, when to refactor code and how to keep the code maintainable.

KEY TAKEAWAYS:

For impatient readers like myself, I’ll cover the key takeaways from this article first.

1. Firstly you should enhance your test cases and add more tests to include the edge cases
2. Never have file/directory changes and code changes in the same pull request. Keep them separate to have a better file changes view in Github or your flavor of version control.
3. Start by refactoring your HTML code, then CSS, and then JS.
4. Make sure the hierarchy oF CSS classes matches that of the HTML
5. The first thing to do in the JS code refactoring is to rename functions to be more readable and split bigger functions into smaller more logical chunks.
6. Once the function/variable name changes are done and you’ve converted your bigger functions into smaller chunks, you can approach the actual code change.
7. Most of the time, a more readable code is much better than having a more optimized code. So make sure you concentrate on the readability of your code first.
8. The best way to grasp best practices is to review more and more Pull Requests.
9. When in doubt what is more readable. just do a poll with your teammates.
10. The best time to do a refactor is after the release is done and you’re just about to start working on the features for the next release.

Enhance your test cases -

It’s always better to first refactor your tests by making sure that you’re covering all the corner cases and have the maximum code coverage. This also becomes super helpful when your current code is QA certified. That way, you can quickly test if the refactored code is working as expected and you didn’t miss out on any feature.

File/Directory changes -

Filename or directory change should always be in a separate PR without any code changes in it. This is because once you change the filename or directory, your version control will show 2 file changes.-1 addition and 1 deletion. If you add code changes to this, it becomes quite hard to review and track what all has been changed. So better make all the filename/directory changes first, raise a PR, get it merged, and then work on the refactoring.

HTML refactoring -

When tackling HTML and CSS code refactoring, start with HTML first, below are a few practices that’ll help you keep HTML more readable, (feel free to add more in the comments) -

• Use correct DOM elements instead of styling divs. For example if you’re adding a header to a component, better to use the header element instead of div with a class of header. That way your CSS specificity will be higher plus the code will be a tiny bit faster to read.
• If you’re using Angular, and you have to use the same components at multiple places in your component, with little change in the props. Turn that into an ng-template and re-use it vai ngTemplateOutlet
• Avoid using unnecessary wrapper divs wherever you can

CSS refactoring -

• Use the same naming convention. There are a lot of naming conventions for your CSS classes, just make sure you follow one of them strictly throughout your project.
• Follow the same hierarchy as your HTML code with your CSS classes in the CSS file. Aka classes that appear first in your HTML should also appear first in your CSS file. If you’re using SCSS, it’s great to next the sub-classes inside the parent classes but make sure not to go beyond 4 levels of nesting, or else you’ll just be creating a mess for yourself.
• Never write the same CSS code twice and put the commonly used CSS code in a common style file.
• Sometimes you might have to write CSS like:
  height: calc(100% — 7.5rem);
  I prefer to write the above code as -
  $footer-height: 7.5rem;
  height: calc(100% — #{$footer-height});
  That way the next person reading this code immediately knows why the height is being decreased without you having to add any comments to the code.

JS Refactoring -

• Start by renaming your functions/variables. In an ideal world, the name of the function should be able to describe the purpose of the function. Some names might feel very obvious to you but might not be so obvious to everyone else. So always put yourself in a reviewer's shoes when you’re naming a function or a variable.
• Split your functions into smaller logical chunks Example: let’s say in your onLoad life cycle hook (onInit or componentDidMount) you need to fire some APIs, fetch some data from the store, initializing a form. Writing all this code together in the lifecycle hook will make your component feel bloated. Instead, do something like this -
  ngOnInit() {
  loadData();
  selectDataFromStore();
  initializePersonForm();
  }
• First priority should be increasing the readability of the code and the second should be the code optimization. I know it’s quite a controversial statement but a code that you can understand quickly, is also the code that you can maintain and optimize easily. While a code that is optimized but poorly written in terms of readability will always be hard to maintain.
• Try having more guard clauses and less if-else nesting.
  I prefer using a switch case whenever there are a lot of if cases, it makes the code neater.
• The best way to write a readable code is to develop empathy towards the next developer who’ll be maintaining this code or reviewing it.
• Review a lot of PRs and grasp the patterns you like and avoid writing code that gave a hard time understanding exactly what’s going on. This will also help you gain a lot of empathy towards naming your functions and variables.
• Let’s say you have 2 functions and both are doing the same task, but you aren’t sure which one is more readable, just take a poll from your teammates. Doing so will give you a lot more insights into how other developers think and in turn help you write more maintainable code

When to refactor code -
Refactoring code is an expensive process. The time spent refactoring the code is the time not spent on developing new features. Plus refactored code needs to be peer-reviewed, QA-ed all over again. So it’s always best to write clean code in the first go itself.

But that’s not always possible mostly due to time constraints or fluctuating requirements. So if a piece of code needs to be refactored, the best time to do so is right after a release. You are still fresh about the feature you developed, the edge cases it contains and its complexities plus other resources like QA aren’t that burdened during this time and would be happy to pick your refactored code.

Did I miss something? Do you follow certain patterns which help you write clean and readable code? Let me know in the comments below or pm me.