Loading ...
Sorry, an error occurred while loading the content.

[XP] Re: refactoring

Expand Messages
  • Donald Roby
    ... refactoring is ... attempt in ... If it produces the same results, sure. But it s pretty dysfunctional as well, and I wouldn t advocate it unless there s
    Message 1 of 129 , Oct 1, 2005
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, Ron Jeffries
      <ronjeffries@X...> wrote:
      > On Saturday, October 1, 2005, at 3:48:27 PM, Michael Feathers wrote:
      >
      > > Philosophically, yes, it can go that way, but the def of
      refactoring is
      > > is about functional behavior, not memory or performance. Altering the
      > > the execution path doesn't change functional behavior and adding new
      > > classes and methods doesn't either unless there is a current
      attempt in
      > > the code to call them up via reflection.
      >
      > Well, yes. And ... just /what/ is "functional behavior"? I can
      > refactor a program in such a way as to make it run for a year
      > instead of a millisecond. Is that "functional"?
      >
      If it produces the same results, sure. But it's pretty dysfunctional
      as well, and I wouldn't advocate it unless there's some value in
      slowing the thing down. And then of course, you do have to keep your
      machine running for that year...

      > The reflection example is an interesting one ... it shows that we
      > could in fact write a program such that nothing we would normally
      > call a refactoring would be one. Take, for example, a program that
      > prints the number of classes and methods in itself. In one sense it
      > works after "refactoring" ... except that it gets a completely
      > different (albeit in some sense correct) answer.
      >
      Reflection is always a good way to generate paradoxical behavior.

      Witness Russell, Godel, Turing ...

      I would be a bit worried about refactoring such a class or testing it.
      If I needed a class that did something like this, I'd be even more
      careful. I'd look real hard for a way to avoid it.

      > My point was, and remains, that as we refactor, we have in mind
      > which "behavior" we intend to preserve, and which we do not. The
      > notion is analogous to the mathematical metaphor that we all share,
      > but as Don Roby has pointed out, it's not exact.
      >
      But then, metaphors aren't supposed to be exact anyway. ;-)

      On some level, it's not exact because it's not worth our trouble to
      make it exact. Math can in fact deal with the finite quite well.

      Certainly when we refactor we do it with a goal, and most applications
      of factoring in algebraic manipulation are goal-oriented as well.

      But I think the basic programming goal of refactoring is to preserve
      *all* behavior of the subsystem undergoing work, in the sense
      described by Opdyke, while preparing for a code change that actually
      changes behavior intentionally.

      > Furthermore, when we refactor, we have changed what the program
      > /is/, even if we have not changed [some more or less narrow subset]
      > of what it /does/. It's a different program, with different
      > possibilities, different ways to be used.

      Setting up to use it in a new way is indeed the usual goal. But we
      don't introduce any new use until the next step.

      > An algebraic factoring, as far as I know, always "works", because
      > the meaning of "works" is so narrow: something like "given any real
      > numbers in the range of the function, both expressions calculate the
      > same value." Even then we have to be careful, lest we insert a
      > division by a number that is potentially zero, or an even root of a
      > number that is negative. In use, as opposed to theory, even
      > algebraic refactorings are chosen by intent, to accomplish some end.
      >
      > A code [re]factoring is trickier. Although it seems to be as
      > formally defined as the algebraic one, it is driven by intent, even
      > more so than the algebraic ones are.
      >
      I think this is where we differ. I think I can even begin to define
      the difference.

      In math and in programming, I hold that the refactorings either exist
      or do not exist, and that there is an algebra of them. Our choice of
      which to use is driven by intent. The definition does not include the
      intent.

      > Now, frankly, I think that none of this matters in real life.
      > Refactoring is a toolbox of code transformations which we choose,
      > using our intelligence, to accomplish goals which we also choose.
      > Its formal definition is perhaps quite useful to a few, but its
      > practical application as part of software development is, to me,
      > more valuable.
      >

      Indeed, much of the formality is only of interest to someone
      interested in formality. But I can't help it - I'm a mathematician,
      so on some level, it interests me in an abstract mathematical way.

      I'm also a programmer however, and pragmatic enough not to worry too
      much about it. I just see a measure of safety in separating the
      behavior-preserving change from the behavior-adding change. We still
      need tests for added safety though, in case we think something's a
      refactoring when it's actually not.
    • aacockburn
      ... Thanks - I was typing fast and my mind went blank. Alistair
      Message 129 of 129 , Mar 6, 2008
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, Tim Ottinger <linux_tim@...>
        wrote:
        >
        > "... of Illinois" (at Urbana/Champaign)
        >

        Thanks - I was typing fast and my mind went blank. Alistair
      Your message has been successfully submitted and would be delivered to recipients shortly.