One way that the lazy avoid refactoring a method name is to leave the old behind and create a new one with a slightly different name. At first it seems like an easy way to keep the codebase stable; all the old code can keep calling the original has-lots-of-problems method, and the new code can call the new efficient method.
As an example, consider the following saveOrderGood method.
public void saveOrder(Order order, User userId)
throws PersistenceException
{
:
}
/**
* Don't use saveOrder any more. It wasn't as good
*/
public void saveOrderGood(Order order, User userId)
throws PersistenceException
{
:
}
The developer made improvements in the form of the saveOrderGood method but left behind saveOrder as a future maintenance problem (also known as Technical Debt), despite knowing that a full refactor to fix the callers would take just a few minutes. Perhaps they didn't bother to check at all.
The old saveOrder method should have been completely removed – a task made easy by modern IDEs.
Other suspect suffixes also indicate refactoring avoidance:
saveOrderBetter
saveOrderBest
saveOrder2
saveOrderThree
saveOrderNew
These kind of method names should not be seen in quality solutions.
