in reply to Refactoring Redux...

Perhaps I'm being pedantic, but you seem to also be adding functionality along with your 'refactoring' -- the end result has different output from the original. My understanding of traditional refactoring is that the resulting code performs the identical function of the original.

So you have two knobs here: the refactoring knob and the 'do more stuff with the increased functionality, modularity, and clarity' knob. By turning both at the same time you risk introducing unknown errors that might slip by your test suite (you have a test suite, right? :)

As I said, I'm probably being overly pedantic. It's always interesting to see snapshots of code evolution, but in this case the code is evolving over at least two directions.

Matt

Replies are listed 'Best First'.
Re: Re: Refactoring Redux...
by chromatic (Archbishop) on Dec 16, 2002 at 20:45 UTC

    That's not overly pedantic. I thought the same thing, but didn't say anything as I'm grumpy today.

    Refactoring is much like simplifying an algebraic (or chemical) equation: at each stage, it must be equivalent. Adding features changes that, and it's a little tricky. It's much harder to reverse a refactoring (and every refactoring is reversable!) if you have added a new feature in between.

[reply]
Re: Re: Refactoring Redux...
by hsmyers (Canon) on Dec 16, 2002 at 20:52 UTC
    Yet another reason to do this sort of thing in public---if your notion is fuzzy, some kind soul will come along and sharpen it for you! I just took another look in Fowler and you are correct. So what do we call refactoring with modification (improvements?)...

    --hsm

    "Never try to teach a pig to sing...it wastes your time and it annoys the pig."
[reply]
      Code Sculpting? :)

      I don't know what to call it. To be honest, though, it's the approach I usually end up taking on my first pass at a coding problem. As I code I gain a better understanding of the problem I'm solving -- this in turn affects how I partition my code as my solution becomes more robust. It's a feedback cycle, and one that causes many software architects to quake in their boots.

      I don't advocate the method for a large-scale design project.

      Matt

[reply]
      So what do we call refactoring with modification (improvements?)...

      The wrong way to do it.

      If you read about refactoring, especially Fowler's book, it specifically admonishes you to only refactor and not extend your code while refactoring. As someone else pointed out you are creating a lot more possibility for broken code.

      You refactor, then you extend, then you refactor again -- etc.

[reply]

        I agree wholeheartedly, and think this approach is one doomed to failure on any large-scale project. Add functionality as you build (Along with making sure you have an up to date and comprehensive suite of unit tests), and then refactor to make the code tidier without changing functionality (And also whilst making sure your test suite keeps working). Rinse and repeat.

        It does seem kind of ironic that the top-level thread started with the observation that people throw words like refactoring around with no real idea of what they are, and then proceeds to do exactly that.

        I think I'm slowly being indoctrinated by the Patterns/Refactoring Cult. It took some of them a considerable amount of time to crowbar some of the ideas into my skull, and a lot of patience to help keep me on the right track (For that methodology, anyway), but now I keep my unit tests fresh and am at least able to talk patternese whilst designed architecture, which helps when dealing with others who're more than able to do such.

[reply]

In Section Meditations