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
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.
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.
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
- Release Notes
- Use Case
- Test Case
- 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.
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.
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