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

[XP] Re: Refactoring...

Expand Messages
  • Phlip
    From: Chris Bitmead ... By introducing a rule that says after it works and before you check it in you go back and clean it up. Or RefactorMercilessly and clean
    Message 1 of 11 , Mar 30, 2000
    • 0 Attachment
      From: Chris Bitmead

      > How does refactoring work in practice? I mean in real life programmers
      > write a part of the project and then they don't re-visit it unless there
      > is a bug.

      By introducing a rule that says after it works and before you check it in
      you go back and clean it up. Or RefactorMercilessly and clean everything up.

      After doing the simplest thing to get past a Unit Test, you now have an idea
      what the code really does. But this might be just a small distance away from
      what it _looks_like_ it does. So you use your fresh ideas while they'r
      currently in your mind to clean up.

      You also remove compromises, such as local variables used twice or large
      blocks of commented-out code, while you remember them. And you also apply
      all the stuff you'v read about good coding style, such as books like
      /Effective C++/ or /Smalltalk Best Practice Patterns/.

      > By what mechanism do you get programmers to continually
      > revisit old code to re-factor?

      OnceAndOnlyOnce. Whenever you add a new feature, you are expected (during
      the RM phase) to prove it really _is_ a new feature.

      > In a regular software project if I said
      > to my manager I want to revisit my old code and re-do it he'd think I
      > was crazy, or incompetant for not doing it right first time.

      Show him how UnitTests change all his ideas of code ownership, fragile lava
      code, and AintBrokeDontFixIt policies. He thinks if you don't change code it
      won't break. What it will do is compromise the design of new code with
      helpless duplications (unless a diety wrote the orginal code and you
      actually can use OCP and extend everything just the way you need it). Show
      him you can migrate the ballast of your project's stability out of the
      static blobs of old code and into your UnitTests...

      Phlip
      ======= http://users.deltanet.com/~tegan/home.html =======
    • Chris Bitmead
      ... Am I mis-understanding refactoring? Cleaning up code and making it good before checking in the first time I would call factoring . refactoring I would
      Message 2 of 11 , Mar 30, 2000
      • 0 Attachment
        Eric Hodges wrote:
        >
        > I don't work in an XP shop, but I refactor before I check code into
        > SourceSafe. Going back weeks or months later is hard, since you have to
        > remember what you were thinking before. I usually try to refactor as I go.
        > When I run into a tought problem I just slug it out, then as soon as it's
        > working I refactor it til it looks good.
        >
        > The best way to get programmers to refactor is to instill a sense of pride
        > in them. Or hire programmers with an innate sense of pride in their work.
        > I'd be embarassed to check un-refactored code in. If I put my name on it,
        > it ought to be beautiful. :)

        Am I mis-understanding refactoring? Cleaning up code and making it good
        before checking in the first time I would call "factoring".
        "refactoring" I would call continually going back and redoing old code
        because

        (a) you now understand the problem better
        (b) you've recognised commonality with other modules
        (c) you've now thought of a better/simpler way/design

        Have I misunderstood what it means? Of course all projects and
        methodologies would claim to do good code "as you go". I thought the
        more unique approach of XP was the continually re-visiting.
      • Phil Goodwin
        ... In XP you have a partner who says: Hey, we can t check this stuff in! We ve got to refactor first. That helps. I refactor a two different times (even
        Message 3 of 11 , Mar 30, 2000
        • 0 Attachment
          Chris Bitmead wrote:
          >
          > How does refactoring work in practice? I mean in real life programmers
          > write a part of the project and then they don't re-visit it unless there
          > is a bug. By what mechanism do you get programmers to continually
          > revisit old code to re-factor? In a regular software project if I said
          > to my manager I want to revisit my old code and re-do it he'd think I
          > was crazy, or incompetant for not doing it right first time.

          In XP you have a partner who says: "Hey, we can't check this stuff in!
          We've got to refactor first." That helps.

          I refactor a two different times (even though I work without a partner
          most of the time): just before I add a feature to the code and just
          after I get it to work. First I make the code a nice place for the
          feature to live (that takes care of really old code) and then I make the
          code for the feature as expressive as possible. New mechanisms mostly go
          in when I'm doing the first kind of refactoring and good decomposition
          and names go into doing the second (since I try to keep structure as
          simple as possible).

          --
          Phil Goodwin, Java Software, Sun Microsystems, 408-517-6951, or x66951

          "There's only so much you can do, and you have to do that much, even if
          you don't know how much it is." --Garrison Keillor
        • Phil Goodwin
          ... Well you don t spend time just looking for bits of the system to re-write. In XP you focus on getting a test to run as quickly as possible instead of
          Message 4 of 11 , Mar 30, 2000
          • 0 Attachment
            Chris Bitmead wrote:
            >
            > Am I mis-understanding refactoring? Cleaning up code and making it good
            > before checking in the first time I would call "factoring".
            > "refactoring" I would call continually going back and redoing old code
            > because
            >
            > (a) you now understand the problem better
            > (b) you've recognised commonality with other modules
            > (c) you've now thought of a better/simpler way/design
            >
            > Have I misunderstood what it means? Of course all projects and
            > methodologies would claim to do good code "as you go". I thought the
            > more unique approach of XP was the continually re-visiting.

            Well you don't spend time just looking for bits of the system to
            re-write. In XP you focus on getting a test to run as quickly as
            possible instead of writing pretty code. Then once the test works you go
            back and pretty up the code. So there is an opportunity to refactor even
            before the code is checked in. You also refactor code when you run into
            problems with it while you are trying to write other code (including
            tests).

            --
            Phil Goodwin, Java Software, Sun Microsystems, 408-517-6951, or x66951

            "There's only so much you can do, and you have to do that much, even if
            you don't know how much it is." --Garrison Keillor
          • Chris Bitmead
            ... One thing that impresses me about open-source/free software projects is that often people are just looking for bits of the system to re-write and doing it.
            Message 5 of 11 , Mar 30, 2000
            • 0 Attachment
              Phil Goodwin wrote:

              > Well you don't spend time just looking for bits of the system to
              > re-write.

              One thing that impresses me about open-source/free software projects is
              that often people are just looking for bits of the system to re-write
              and doing it. Like Linux for example. Nobody is ever satisfied with any
              part of it because it can always be improved.

              On the other hand I bet if we could spy on the developers of SCO Unix,
              they never look at anything unless a level 1 bug report comes in. You'll
              never find anybody changing something just because it seems like a good
              thing.

              Couldn't extreme programming do with even more extreme refactoring?
            • Ron Jeffries
              ... Refactoring is the act of changing code structure without changing function, no matter when you do it. So if you write the code quick and dirty, or even
              Message 6 of 11 , Mar 30, 2000
              • 0 Attachment
                At 10:58 AM 3/31/2000 +1000, you wrote:
                >Am I mis-understanding refactoring? Cleaning up code and making it good
                >before checking in the first time I would call "factoring".

                Refactoring is the act of changing code structure without changing
                function, no matter when you do it. So if you write the code quick and
                dirty, or even slow and not quite clean, then clean it up before release,
                it's refactoring.

                >"refactoring" I would call continually going back and redoing old code
                >because
                >
                >(a) you now understand the problem better
                >(b) you've recognised commonality with other modules
                >(c) you've now thought of a better/simpler way/design
                >
                >Have I misunderstood what it means? Of course all projects and
                >methodologies would claim to do good code "as you go". I thought the
                >more unique approach of XP was the continually re-visiting.

                We would not recommend revisiting code just for the heck of it. That would
                be wasteful of the company's money. We "require" that when code is checked
                in, it meets the rules of simplicity: run the tests correctly; express all
                the ideas you need to express; have no duplication; have minimal classes
                and methods.

                You refactor right away to get the code that way, and when you make
                changes, you refactor either to make room for the change or to clean up
                after it. Naturally people do clean up random code a bit "on their own
                time", but that's not the standard practice.

                Regards,

                Ron Jeffries
                www.XProgramming.com
              • Gareth Reeves
                Refactoring is such a big part of XP because you can t always do the simplest thing possible without it. I do most of my refactoring when a new feature is
                Message 7 of 11 , Apr 3, 2000
                • 0 Attachment
                  Refactoring is such a big part of XP because you can't always do the
                  simplest thing possible without it.

                  I do most of my refactoring when a new feature is added to the system. Doing
                  the simplest thing possible in today's code means that I can't account for a
                  feature that may be introduced in a week. When (and if) that feature is
                  introduced I then have to refactor the code to fit it in.

                  IMHO this is a wonderful way of evolving a system, as Bob Martin says, 'its
                  self organizing'.

                  What is also important about this approach is that you don't end up with
                  dead code that isn't used. I like using coverage tools to verify this.

                  Gareth


                  -----Original Message-----
                  From: Ron Jeffries [mailto:ronjeffries@...]
                  Sent: Thursday, March 30, 2000 7:42 PM
                  To: extremeprogramming@egroups.com
                  Subject: [XP] Re: Refactoring...


                  At 10:58 AM 3/31/2000 +1000, you wrote:
                  >Am I mis-understanding refactoring? Cleaning up code and making it good
                  >before checking in the first time I would call "factoring".

                  Refactoring is the act of changing code structure without changing
                  function, no matter when you do it. So if you write the code quick and
                  dirty, or even slow and not quite clean, then clean it up before release,
                  it's refactoring.

                  >"refactoring" I would call continually going back and redoing old code
                  >because
                  >
                  >(a) you now understand the problem better
                  >(b) you've recognised commonality with other modules
                  >(c) you've now thought of a better/simpler way/design
                  >
                  >Have I misunderstood what it means? Of course all projects and
                  >methodologies would claim to do good code "as you go". I thought the
                  >more unique approach of XP was the continually re-visiting.

                  We would not recommend revisiting code just for the heck of it. That would
                  be wasteful of the company's money. We "require" that when code is checked
                  in, it meets the rules of simplicity: run the tests correctly; express all
                  the ideas you need to express; have no duplication; have minimal classes
                  and methods.

                  You refactor right away to get the code that way, and when you make
                  changes, you refactor either to make room for the change or to clean up
                  after it. Naturally people do clean up random code a bit "on their own
                  time", but that's not the standard practice.

                  Regards,

                  Ron Jeffries
                  www.XProgramming.com

                  ------------------------------------------------------------------------
                  To Post a message, send it to: extremeprogramming@...
                  To Unsubscribe, send a blank message to:
                  extremeprogramming-unsubscribe@...
                  Ad-free courtesy of objectmentor.com

                  ------------------------------------------------------------------------
                  -- Check out your group's private Chat room
                  -- http://www.egroups.com/ChatPage?listName=extremeprogramming&m=1
                • Kent Beck
                  Couldn t extreme programming do with even more extreme refactoring? Once and Only Once applies across the entire system. Think about it. I can t get more
                  Message 8 of 11 , Apr 3, 2000
                  • 0 Attachment
                    "Couldn't extreme programming do with even more extreme refactoring?"

                    Once and Only Once applies across the entire system. Think about it. I can't
                    get more extreme than that. Can you?

                    Kent
                  • Chris Bitmead
                    ... Twice across the system? Three times? Is code ever perfect, or even close?
                    Message 9 of 11 , Apr 3, 2000
                    • 0 Attachment
                      Kent Beck wrote:
                      >
                      > "Couldn't extreme programming do with even more extreme refactoring?"
                      >
                      > Once and Only Once applies across the entire system. Think about it. I can't
                      > get more extreme than that. Can you?

                      Twice across the system? Three times? Is code ever perfect, or even
                      close?
                    • Kent Beck
                      Twice across the system? Three times? Is code ever perfect, or even close? Every unreconciled duplication is a learning opportunity missed. The code is never
                      Message 10 of 11 , Apr 4, 2000
                      • 0 Attachment
                        "Twice across the system? Three times? Is code ever perfect, or even
                        close?"

                        Every unreconciled duplication is a learning opportunity missed.

                        The code is never perfect. Close is okay. Think Wabi Sabi.

                        Kent
                      Your message has been successfully submitted and would be delivered to recipients shortly.