August 22, 2022 Refactoring, Simple Design, Evolutionary Design
This is a companion discussion topic for the original entry at https://blog.thecodewhisperer.com/permalink/what-is-the-right-amount-of-refactoring
This is a companion discussion topic for the original entry at https://blog.thecodewhisperer.com/permalink/what-is-the-right-amount-of-refactoring
https://twitter.com/sf105/status/1562687125283188736
There is another reason to refactor which is to embody understanding, so one doesn’t have to re-interpret the code the next time. Of course, that assumes that the new version is “better”. – @sf105
I infer that “embodying understanding” means something such as improving names in order to reduce the cost of future changes. I do this as a part of Cleaning Up Before Moving On.
In its strictest sense, I feel forced to consider this speculative, although I trust my intuition, so I feel significantly less risk in speculating in this way. Another programmer, unfamiliar with my work and unaccustomed to my style, might consider it very risky indeed. We’d need to negotiate.
This explains in part why I consider speculative refactoring unavoidable and even desirable. If there were literally none, then that would drive up the cost of future refactoring: it would withhold information helpful to future programmers working on that part of the code.