When Not to Refactor
There are situations when refactoring makes less sense than it normally does. One such situation is when refactoring comes at the expense of performance. Contrary to Fowler's otherwise masterful treatment of the subject, I do not believe that refactoring code such that it performs poorly is a good idea, regardless of the frequency with which it is called. In Refactoring, Fowler[13] provides an example in which a temporary variable is eliminated by calling a function repeatedly rather than caching its result. So, rather than having a single call to the function, with its result stored in a variable that is then referenced by the remainder of the method, we have multiple calls. Each time the function's result is needed, the ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access