Thinking of refactoring some code?

If you've spent any time at all coding on an older application, perhaps as part of a large, distributed team, you'll likely be very familiar with the concept of "refactoring code". None the less, for those not familiar with the term, here is one particularly succinct definition that I personally feel encapsulates the goal of the process perfectly. 

To rewrite existing source code in order to improve its readability, reusability or structure without affecting its meaning or behavior.

Without doubt, there are a great many benefits to refactoring code, particularly the older, less elegant code in a given application. However, it goes without saying that there are a number of additional points to consider before embarking on a significant refactor project.

1. You should only attempt a refactor when your project/milestone timescales allow. There are often complications associated with some refactor projects, so be sure that your project can accommodate the additional workload -- both in terms of development and the additional QA time.
2. If you are going to refactor code, you will likely need to increase your developer testing effort to ensure that the changes have not adversely affected existing functionality.
3. If you are planning a large-scale refactor, try to make the changes on a project where significant testing and regression budgets have been set aside.
4. Where at all possible, try to keep your refactor separate from functional changes. This helps significantly in communicating the details of the refactor versus functional/feature changes during code review and when looking back at the history in the milestone.
5. Due to the sheer scale of some applications, the scope of the functional items covered in regression often changes; regression also does not necessarily cover all features of an application. Therefore, it is not a given that QA team regression will pick-up on items affected by a refactor and it is a developers responsibility to call out specifically affected items to QA prior to the regression testing.

And finally, no matter how much developer/QA testing we go through, a large refactor will inevitably generate additional errors/problems for the rest of the team. If we want engineers to refactor and improve the codebase, and we absolutely do, we must accept that there will be potential fallout and be prepared to help fix any issues that come to light.

Happy refactoring!