Rustom Mody <rustompm...@gmail.com> writes: > You may find this strategy useful: > https://pchiusano.github.io/2015-04-23/unison-update7.html > > particularly the section "Limitations of refactoring via modifying > text files in place, and what to do instead"
A direct link to that section is <URL:https://pchiusano.github.io/2015-04-23/unison-update7.html#refactoring-lessons>. The author points out there are times when a code base is large and complex enough that refactoring puts the programmer in a state of not knowing whether they're making progress, because until the whole refactoring is complete the errors just cascade and it's hard to tell which ones are relevant. That’s bad for two reasons. Without this feedback, you may be writing code that is making things worse, not better, building further on faulty assumptions. But more than the technical difficulties, working in this state is demoralizing, and it kills focus and productivity. All right, so what do we do instead? Should we just avoid even considering any codebase transformations that are intractable with the “edit and fix errors” approach? No, that’s too conservative. Instead, we just have to *avoid modifying our program in place*. This lets us make absolutely any codebase transformation while keeping the codebase compiling at all times. Here’s a procedure, it’s quite simple […] <URL:https://pchiusano.github.io/2015-04-23/unison-update7.html#refactoring-lessons> The technique is not presented as flawless, and interesting trade-offs are discussed. Quite an interesting article. -- \ “Science and religion are incompatible in the same sense that | `\ the serious pursuit of knowledge of reality is incompatible | _o__) with bullshit.” —Paul Z. Myers, 2010-03-14 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
