Java Reference
In-Depth Information
When should one consider refactoring?
Ideally, refactoring would be part of a continuing quality improvement process. In other
words, refactoring would be seamlessly interwoven with other day-to-day activities of every
software developer.
Refactoring may be useful, when a bug has surfaced and the problem needs to be fixed or
the code needs to be extended. Refactoring at the same time as maintenance or adding new
features is useful. This makes management and developers more likely to do it, since it will
not require an extra phase of testing.
Often, however, schedule pressures do not permit to implement a clean solution right away.
A feature may have to be added in a hurry, a bug patched rather than fixed. Since project
timelines are tight, individual refactoring cases can not be taken. In such cases a complete
refactoring project can be taken when size of refactoring work becomes large. In the mean-
while all cases requiring refactoring needs to be marked.
However delaying refactoring activities is not a good practice. When you write fresh code
and find some problems during debugging which point to a need for refactoring then you
should not delay and do it right there. Carrying out a few refactoring operations before or
during code debugging may have immediate benefits. Often it becomes easier to spot the
bug location. So time is saved, while at the same time the quality of the code is enhanced.
Well-structured code is also less error-prone when it comes to extending it.
Here are a few pointers for a case for refactoring:
•
Programs that are hard to read are hard to modify.
•
Programs that have duplicate logic are hard to modify
•
Programs that require additional behavior that requires you to change run-
ning code are hard to modify.
•
Programs with complex conditional logic are hard to modify.
While sometimes there are immediate benefits to be reaped from refactoring, the real bene-
fits normally come in the long term. They consist in substantially reduced time that deve-
lopers spend on debugging and maintenance work, as well as in improved extensibility and
robustness of the code. In addition, code duplication is reduced, and code re-use fostered.
Overall maintenance and development cost should come down, and the speed of the team to
react to changing needs should improve.
