5 Tips for Refactoring Code

Requirements change, QA sends builds back, you inherit old code or your tech stack needs to be updated. Either way at some point you’ll have to venture down the path of refactoring. This guide will help you avoid some common pitfalls saving you time and frustration. 5. Write A Plan Ahead Of Time Add description No alt text provided for this image Before you begin refactoring code, create a plan of action. Starting with the requirements, jot down a list of what is currently available and what needs to change. You should be able to answer the following questions. What are the new requirements? How much of the current code can solve the new requirements? What impact will your changes have on the application? Will other developers be affected by your change? When and How will the code be integrated? 4. Share Your Plan With the team, Don’t Develop In A Silo. Add description No alt text provided for this image Refactoring code is a collaborative effort, though you may be responsible for the coding, It’s still a good idea to communicate with your fellow developers. From undocumented nuances, dependencies or integration insights, other developers can be a wealth of knowledge. Methods for Requesting Feedback On smaller teams Take the time to really think through your questions thoroughly and write them down. Respect goes a long way, so respect their time by being prepared. When you’re ready simply ask “When you get a chance can I run a few things by you?”. Test-Driven Development Teams It is normal to have conversations with developers offline but typically a pull request is made with unit tests. Those tests are then reviewed by the team where they can give feedback on the ideas and structure. Weekly Peer Code Reviews Some teams do weekly code reviewers which give you an opportunity to grow and learn as a team by reviewing each other’s code. During these reviews, it’s important that you are an active percipient. As questions and point out areas of overlap with what you are working on and others. 3 Unit Test Before Coding Prior to rewriting a line of code, you should have as much unit testing code coverage as possible. There is a high likely hood that functionality will be broken and without a solid benchmark of the original features, it will be difficult to know what is missing. How much is enough unit testing? 100% code coverage is a good goal to attain, however, the most important factor is workflow. At the very minimum, your unit test should cover both success and error paths. If there are multiple features or methods those should be tested as well. Ideally, you want to limit the number of supprises and use the tests as key indicators of success. 2 Documentation There are so many times that decisions are made in code and the original developer is no longer around to explain. Documentation will keep that knowledge flowing and living in the application. In cases where the original developer is still accessible, documentation allows for the transfer of knowledge without the overhead of continual onboarding. Any developer can read the in-code documentation and get a sense of what was done and how to use it. By properly documenting your code editors can read the documentation and provide code hinting. A really good example is using the JSDOC @depecrated tag. Webstorm, Visual Studio, RIder, and other modern IDEs will cross out any usage of a deprecated function or methods. That IntelliSense is priceless, as you can see in the images bellow having immediate feedback while the type of usage errors or code hinting makes the process go much faster. Add description JSDOC Code Hint Deprecated Code Add description Code Hinting For Arguments Along with in-code documentation here is a list of other documents you should consider writing Release Notes Use Case Test Case Requirements Changelog Update Bug or Issues in project management 1. A Controlled Integration and Release Strategy You are feature-complete and now ready to begin the integration process. The first thing you want to do is list the areas that will be affected. For each identified area, update and then test. Those tests can be some or all of the following. Unit Tests Integration Tests End To End Tests Regression tests Mock or Live Data If at all possible you should use live data for testing if you don’t have access to live data; accurately mocked data will be the next best thing. Though randomized text generators are great for initial development, you want to make sure your data is the same word and sentence length and uses similar characters. Deployment Strategies There are a number of techniques to release new code, each with there strengths and weaknesses. The overall goal is to get your code in a controlled and predictable way to the end-users. Below is a list of possible options for deploying. Massive One Time Deploy: Release new code to every user all at once Canary Release: Controlled release to a small set of users, primarily used to test infrastructure and workload. Overtime the release covers the full infrastructure Blue-Green: Zero downtime release that often includes full infrastructure updates. If release passes old builds are replaced by new builds overtime. If errors do arise reverting is typically faster then the others. Conclusion With a good plan and great communication, you can make the process of refactoring code from requirements to deployment as predictable and reliable as possible. It’s time to put what you learned into practice Let’s Get At It Resources: Mocking Library Chance What You Need To Know About Unit Testing

Notes

Voiced by Amazon Polly

Requirements change, QA sends builds back, you inherit old code or your tech stack needs to be updated. Either way at some point you’ll have to venture down the path of refactoring. This guide will help you avoid some common pitfalls saving you time and frustration.

5. Create A Plan Of Action

Developers Looking At Code


Before you begin refactoring code, create a plan of action. Starting with the requirements, jot down a list of what is currently available and what needs to change. You should be able to answer the following questions.

  1. What are the new requirements?
  2. How much of the current code can solve the new requirements?
  3. What impact will your changes have on the application?
  4. Will other developers be affected by your change?
  5. When and How will the code be integrated?

4. Share Your Plan With the team, Don’t Develop In A Silo. 

people talking

Refactoring code is a collaborative effort, though you may be responsible for the coding, It’s still a good idea to communicate with your fellow developers. From undocumented nuances,  dependencies or integration insights, other developers can be a wealth of knowledge.

Methods for Requesting Feedback


On smaller teams

Take the time to really think through your questions thoroughly and write them down. Respect goes a long way, so respect their time by being prepared. When you’re ready simply ask  “When you get a chance can I run a few things by you?”.

Test-Driven Development Teams

It is normal to have conversations with developers offline but typically a pull request is made with unit tests. Those tests are then reviewed by the team where they can give feedback on the ideas and structure.  

Weekly Peer Code Reviews

Some teams do weekly code reviewers which give you an opportunity to grow and learn as a team by reviewing each other’s code. During these reviews, it’s important that you are an active percipient. Ask questions and point out areas of overlap with what you are working on and others. 

3. Unit Test Before Coding


Prior to rewriting a line of code, you should have as much unit testing code coverage as possible. There is a high likely hood that functionality will be broken and without a solid benchmark of the original features, it will be difficult to know what is missing. 

How much is enough unit testing? 

100% code coverage is a good goal to attain, however, the most important factor is workflow. At the very minimum, your unit test should cover both success and error paths. If there are multiple features or methods those should be tested as well. Ideally, you want to limit the number of supprises and use the tests as key indicators of success.

2. Documentation


There are so many times that decisions are made in code and the original developer is no longer around to explain. Documentation will keep that knowledge flowing and living in the application. In cases where the original developer is still accessible, documentation allows for the transfer of knowledge without the overhead of continual onboarding. Any developer can read the in-code documentation and get a sense of what was done and how to use it. 

By properly documenting your code editors can read the documentation and provide code hinting. A really good example is using the JSDOC @depecrated tag. Webstorm, Visual Studio, RIder, and other modern IDEs will cross out any usage of a deprecated function or methods. That IntelliSense is priceless, as you can see in the images bellow having immediate feedback while the type of usage errors or code hinting makes the process go much faster.

Along with in-code documentation here is a list of other documents you should consider writing  

  1. Release Notes
  2. Use Case
  3. Test Case
  4. Requirements
  5. Changelog
  6. Update Bug or Issues in project management 

1. A Controlled Integration and Release Strategy


You are feature-complete and now ready to begin the integration process. The first thing you want to do is list the areas that will be affected. For each identified area, update and then test. Those tests can be some or all of the following.

  • Unit Tests
  • Integration Tests
  • End To End Tests
  • Regression tests

Mock or Live Data

If at all possible you should use live data for testing if you don’t have access to live data; accurately mocked data will be the next best thing. Though randomized text generators are great for initial development, you want to make sure your data is the same word and sentence length to ensure visual fidelity. 

Deployment Strategies


There are a number of techniques to release new code, each with there strengths and weaknesses. The overall goal is to get your code in a controlled and predictable way to the end-users. Below is a list of possible options for deploying. 

  • Massive One Time Deploy: Release new code to every user all at once
  • Canary Release: Controlled release to a small set of users, primarily used to test infrastructure and workload. Overtime the release covers the full infrastructure
  • Blue-Green: Zero downtime release that often includes full infrastructure updates. If the release test passes old builds are replaced by new builds overtime. If errors do arise reverting is typically faster then the others.

Conclusion


With a good plan and great communication, you can make the process of refactoring code from requirements to deployment as predictable and reliable as possible. It’s time to put what you learned into practice
Let’s Get At It

Resources:

Mocking Library Chance
What You Need To Know About Unit Testing

You May Also Like
Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email

Signup NOW and Never be late again

Get all the latest content regularly and stay up to date with all the latest tools, techniques and industry news.