Role of “Refactoring” in good programming pratices?

Question

I have learned in Agile Development that:

Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior.

I have heard about some GUI refactoring tools like ReSharper and DevExpress Refactor Pro!

Here are my questions:

1. How does it takes place in the Software development process and how far it effects the system?
2. Does Refactoring using these tools really speed up the process of development/maintenance?

Answer 1

First of all, depending upon the site of refactoring one can distinguish several types of it: code refactoring, database (schema) refactoring, refactoring of unit tests, refactoring of GUI etc.

There are several situations where you can meet refactoring during software development:

1. Refactoring is known to be a mandatory step in certain agile development techniques like test-driven development. It is supposed to perform refactoring step after every implementation step. In this case the refactoring targets just the last implementation and its goal is to integrate the new code into the existing code corpus in the most optimal way.

2. Refactoring can be done some internal problems in the working code are detected: this is called "code smell". This estimation is in many aspects rather subjective, despite the fact that it can be actually based upon certain code metrics (like number of lines of code per method, cyclomatic complexity of the code etc.). Here the goal of refactoring is to improve the code quality by changing it so that the metrics used for quality estimation return to the expected domain.

3. You often need to refactor the code to achieve certain principles of programming in your code, look for Clean Code development to learn more about such principles.

4. You may need to perform refactoring of your code and database schema to prepare it for coming changes, especially if those were not considered during the design phase of the project. For example data normalization and denormalization take often place during data-driven software development to prepare the database for possible extensions.

Refactoring tools available on the market basically support the developer in two ways:

1. While writing your code, you get suggestions how you can improve it "on-the-fly". Whereas many fallacies can be detected directly by your IDE, like Visual Studio or Eclipse (for example dead code, variables declared but not used etc.), the refactoring tools like Resharper can reveal problems which are far less evident, like re-writing the loops in LINQ queries etc.

2. These tools also support you with custom refactoring steps, like global renaming of your identifiers, splitting your class declarations into separate properly named files, extracting interfaces and base classes from your class implementation etc. They save a lot of work here, especially if your project has a large code base, but you must first know what you really want to refactor.

Actually using tools like ReSharper in everyday's development is so useful that it makes you almost dependent on them: they really accelerate the process of code writing, especially if you know how to use them appropriately!

Answer 2

I think refactoring is like brushing your teeth. It's a chore that doesn't yield immediate benefits, but should be done routinely and quickly before the dentist ends up refactoring your teeth for you.

Answer 3

Refactoring does have immediate benefits. When programming in a Red-Green-Refactor mode, when you are transitioning from Red to Green, you are in "draft" mode: you don't worry about duplication necessarily, you don't worry about naming, you don't worry about the quality of your solution. This state produces user-value rapidly. When you switch to transitioning between Green and Refactored, you switch into "polish" mode: you don't worry about the domain and users, you worry about the code quality. This is when you express your craftsmanship.

Both modes provide real immediate benefits. (If for no other reason, checking in un-crafted code will harm your reputation on your team.) By explicitly alternating modes, you can achieve higher "flow" / overall productivity.

Answer 4

How does it takes place in the Software development process and how far it effects the system?

Merciless refactoring is a standard practice in all teams I work with. The emphasis is on 'merciless'. If code doesn't 'feel' right it probably isn't. Typically this is called a 'code smell'.

In general we refactor as soon as possible, typically at a time when all tests pass. We stop refactoring once we cannot think of any further way to simplify the code.

Sometime we refactor towards a particular design pattern, e.g. when we have identified the need for a particular interface. Sometimes we change the implementation to address a performance issue. In that sense there are cases when refactoring affects the system. In general however, our refactorings do not change the systems behavior.

Does Refactoring using these tools really speed up the process of development/maintenance?

The best option would be to have data to answer this question. I don't. However, based on observation in my experience fully refactored code is much easier to work with. It is easier to extend. It is easier to locate the source of a bug. By removing code duplicates you not only follow the DRY principle (Don't Repeat Yourself) but you also avoid having to fix the same bug more than once.

Using tools is mandatory. Manual refactoring is possible but tools can take care of most of the cases and are a real time saver.

Based on my observations and my experience working with a number of teams and systems refactoring supported by tools speeds up both development and maintenance of source code.