Everything You Should Think About Before Rewriting

Blog Barista: Sam Nadarajan | Mar 27, 2019 | Development Practices | Brew time: 5 min

As a developer, have you ever been in a situation where you needed to add a feature to an existing part of an application and then realized that the existing code could have been better designed and/or written? Perhaps you will be tempted to refactor the existing code as part of your new feature so that it is cleaner and more performant. While these are valid and beneficial reasons for refactoring code, should you always refactor existing code for the sake of improvement?

The TL;DR answer: it depends.

Recently a group of developers at KL&A sat down to discuss this pertinent issue and the ways it can be avoided or executed better. When it comes to refactoring your code, your answer should not always be “fix it immediately.” There are some considerations to take into account before you start refactoring code.

Remember the End Goal

All the members on your team are working towards an end goal. And the goal is simple, create a successful project that will make your users happy. Trying to fix more than necessary (especially if it is not critical or the scope is too large) could push back deadlines and lead to unhappy users.

Record Identified Changes

Your team may be in agreement that some of the code you found needs to be addressed. However, it’s the end of a sprint, one member of the team is out sick, and your team cannot afford to carry over tickets into another sprint. Instead of ignoring the issue, consider implementing a follow up action item—whether it is a “To-Do” comment in the code or creating a backlog ticket in your ticketing system. Taking these steps may help the next person address the issue should circumstances allow for it.

Communicate During Standups

Daily standups, or scrum meetings can serve as excellent opportunities for you to bring up potential code refactors and initiate the discussion to either fix it or leave it alone. Other developers, analysts, and your project manager can bring up factors to consider that you may have overlooked.

Project Limitations

Refactoring code may be useful for developers and the code base for the long term, but does the project have room to address it now? If the project is on a tight schedule, every minute counts. Code refactors will consume time that could be spent delivering requirements. Teams should also consider the cost of the refactor. Chances are, your users will not want to pay for the code refactor because there is no visible end value for them.

The Stakeholders

It’s easy to find yourself in a single track mindset and conclude that your proposed fix will be done so fast that no one will ever know it was even an issue. But, have you considered the other stakeholders in your fix who will also be held accountable?

Your changes may require a business analyst/project manager to get involved to either test your changes or work with users to get them approved. The changes will also require users to test a part of the application they already tested, which may throw your UAT cycles off course. Most of the time, other people may be involved to make sure that your changes do not break already tested features.

Improving the Overall Technical Environment

If you have been given the green light to go ahead and optimize the code, consider improving the overall technical environment. For example, improve test coverage as part of your fix. Before implementing your fix, check to see if any test coverage exists for the affected areas. If there is none, add test coverage so you know how the system should behave once your fixes are implemented. Then, add your fix and any additional test coverage. This will improve the strength of your code and make future refactors safer.

In addition, document your changes so that others can see why things were done a certain way in the first place. In retrospect the code may not make sense, but there might have been a solid reason for coding that route in the first place. End the cycle of guesswork by documenting your changes and explaining why (if and where necessary) to improve the overall clarity of the system.

Furthermore, use the identification of code that needs refactoring as an educational opportunity. Share your findings with the team so the mistake is not repeated in current or future development. The code refactor may not go through, but if it can be repurposed to make your team stronger, increasing the chances of a successful project.

When to Stop or Resist

What may often seem like a quick fix, can easily lead down a rabbit hole of multiple fixes. If you end up submitting a pull request with hundreds of file changes (for that “small fix”) then you probably went too far. Exercising discipline and constantly reevaluating the necessity and scope of your fix will reduce wasted time.

For every technical reason that supports refactoring code, there are business reasons to consider before refactoring. Risk, testing, timelines, resources, and other factors will be affected even if they are not immediately obvious. Take these into account before drawing conclusions, and think about the current circumstances that may support or reject the idea. Use the experience of determining the necessity of refactoring code to implement preventative measures, such as improving education/communication, instead of relying solely on cures used throughout the project lifecycle. Your team will become stronger because of it, which in turn will strengthen each project that follows.

Other recent posts: