Refactoring is the process of taking some existing code and improving its quality. This process aims to make software simpler, more modular, more efficient, or more stable, and can be done while fixing other bugs.
Refactoring takes surprisingly little time once the risk analysis has been done, especially with an IDE that has refactoring options. Be meticulous and sensible about it, of course - don't refactor the night before a major release. If you don't have the time or scope to refactor, at least add a TO DO and comments to note areas that could be improved, but nobody likes a commenter who never puts their words into action.
In the example below, a developer found that this was the only place in the code where the constant EXPORT_DIRECTORY_PROPERTY was referenced, but there were fifteen magic strings that referred to “export.directory” elsewhere.
protected void initialize() throws Exception
{
// determine the important directory references
String exportDirName = getConfig().getProperty(“export.directory”);
:
The correct (but rarely seen) approach would be to carefully examine and replace each magic string with the reference to the constant.
:
public static final String EXPORT_DIR_PROPERTY = “export.directory”;
:
protected void initialize() throws Exception
{
// determine the important directory references
String exportDirName = getConfig().getProperty(EXPORT_DIR_PROPERTY);
:
For large teams (e.g. greater than 2 developers) the only option might be to do serious refactors at night after everyone has gone home. Give the programmers plenty of notice the ground will be changing under their feet so they can ensure everything is checked in. And be meticulous.
Exception
Some people use refactoring as an excuse for redeveloping code they do not understand or to avoid focus on their lack of performance. No refactoring should occur unless the existing source is clear and it should take at most an iteration to complete, not months. Don't be the team that spends years refactoring without delivering customer value.
