Refactoring in a large code base (was: importing: what does "from" do?)

[Ben Finney]

Rustom Mody <rustompmody at 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