Skip Navigation Links > Coding > Refactoring


A typical outcome of a code review is the recommendation to refactor parts of the source code. Refactoring aims to change the internal structure of working software in order to increase its quality and value, but without changing its observable behavior.

Refactoring changes are completed in small well-controlled increments followed by automated regression tests to verify that the functionality has not changed. Finally, the same set of measurement criteria used in the last review is applied again to collect data for comparison. If the refactoring was successful then the data, which drove the refactoring step in the first place, should be out of the "red".

Refactoring is a natural concept applied in everyday life. For example, after composing a body of text in a document we often read what we have written and then reorganize the structure in order to improve readability, but without changing the meaning of the content. We also use refactoring in mathematics. In arithmetic 6432 can be factored into 32*3*67, or better yet into 8*12*67. In algebra (x² - y²) can be factored into the form (x+y)(x-y) to eliminate the need for an exponent operator. Hence, it should come as no surprise that refactoring is also applied in software development projects. refactoring

Suppose we have two classes in a system that do not share a common superclass and both implement very similar or identical behavior. It would therefore be advantageous to refactor these two classes by moving the common behavior into a shared superclass, and changing the classes so that they descend from that class.

Software is essentially complex, and if it is useful software then it will be frequently modified to adapt to changing business requirements. This leaves plenty of opportunity for accidental complexity to spread. To maintain the value of your software, you need to perform code cleanup and reorganization tasks after each release.

Not every developer is capable of refactoring code. To perform this task a person must have an innate desire and ability to organize and structure things. This characteristic cannot be learnt; you are either born that way or you are not. Some programmers can produce large quantities of working code in a short space of time. On the surface such people appear to be very productive, however if the code they produce is messy and difficult to understand then the time required by others to refactor it into a maintainable form will absorb any time advantage that was gained by programming in a hurry.

One should consider replacing a problem-area in the code with a recommended solution from the refactoring catalog and/or a design pattern. The use of design patterns in the refactoring stage can save a lot of time, since these represent proven solutions to commonly encountered problems. Professional design patterns are well documented and straightforward to apply, however sound judgment is always required; be on guard against over-engineering.

Refactoring improves your source code by making it:

  • easier to read and understand.
  • less expensive to modify.
  • more efficient.
  • more robust.
  • more elegant and professional.
  • easier to reuse.
  • easier to keep clean.
  • easier to test.

Refactoring increases the value of your software investment and saves money that would otherwise be spent in maintaining non-optimized code.



Quote Start Refactoring is essential for maintaining software quality and contributes greatly to the long-term success of a project.


Quote Start Neglecting the refactoring step is equivalent to taking on technical debt.


Quote Start Passing on undisclosed technical debt to an unwitting customer is software malpractice.


Quote Start Resist the urge to hurry; it will only slow you down.

Top-of-page | Review | Testing | Refactoring | Tutorials