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.
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.
Summary
Refactoring is essential for maintaining software quality and contributes greatly to the long-term
success of a project.
Neglecting the refactoring step is equivalent to taking on technical debt.
Passing on undisclosed technical debt to an unwitting customer is software malpractice.
Resist the urge to hurry; it will only slow you down.