The right (and wrong) way to think about code refactoring

When and why do I need to refactor code?

Poor coding habits and non-adherence to proper design guidelines can lead to duplicated code, improper dependencies between the classes and improper allocation of responsibilities within the classes and methods. Instead of substandard practices that result in inefficient, difficult-to-maintain code, code refactoring helps you maintain good, dependable code hygiene.

Teams should first refactor an application's code before adding any new features or updates to the existing code, and then should follow up on the refactor with thorough testing. It is possible to refactor the code after the release launches, but remember that you should only refactor working code after all your tests come back clean.

If you plan to launch an application onto the market within a short span of time, don't plan to refactor code before the launch. It's usually a time-consuming process, and it could delay the delivery process. Moreover, you would need to perform additional testing after the refactor to ensure that you didn't alter the application's functionality and it still works as expected.

Some proven techniques for refactoring

Several different strategies exist for code refactoring. Here's a look at some prevalent approaches.

Red-green refactoring

Teams that prioritize test-driven development widely use the red-green approach to refactor code. This approach organizes the entire refactoring process into three steps:

• Red -- stop and think about what you need to develop.
• Green -- write just enough code to ensure that tests pass.
• Refactor -- optimize and clean code without adding new functionality.

Refactor by abstraction

This technique extracts your code, abstracts it and helps you avoid duplicated code. There are two variations of this technique: the pull-up and push-down. The pull-up technique moves the code to a super class to avoid duplication, whereas the push-down method moves the code from the super class down to a sub class for the same purpose.

Composing methods

Methods that are excessively large are not easy to manage, change or maintain over time. This approach takes advantage of extraction -- including method, class, interface and local variables -- to simplify the code and make it easier to change.

Simplifying methods and conditionals

Over time, code grows and becomes more complex. You can simplify your method logic by adding parameters, removing parameters, renaming methods or simplifying conditionals by replacing them with polymorphism.

Preparatory refactoring

This is a technique in which the developer anticipates the need to refactor the code before adding a new feature. By updating the code before adding a new feature, this approach reduces future technical debt.

Best practices

Code refactoring is a continuous process. No matter how many times you refactor, you may never be entirely satisfied because code refactoring begets more code refactoring. Therefore, it's worth it to focus on continuous progress rather than the so-called application perfection.

Accept refactoring as an ongoing maintenance activity, because code factoring is designed to support adaptation. It's likely that the code you refactored once might become stale over time, and you'll need to refactor it once again.

With that in mind, there are several fundamental practices to follow when you refactor code:

• Baseline your code and make sure that the code can be tested before you start refactoring. Have a test strategy in place and be sure the tests have good coverage, as well.
• Run the tests after every change in the code. This ensures that the code refactoring process didn't alter any functionality or introduce new bugs. It is also a best practice to have all the required tests available before refactoring the code.
• Take advantage of the many code refactoring tools available. For example, Microsoft's Visual Studio IDE contains built-in tools for code refactoring. You can easily rename, extract and format source code within the IDE.
• Refactor your code gradually. Refactoring should be a step-by-step process. After every step is complete, test the code thoroughly.
• Refactor before new features are added, or before the application is updated.

Author's note: You can read the book "Refactoring: Improving the Design of Existing Code" by Martin Fowler for further reference on code refactoring.