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

refactoring

Expand Messages
  • acockburn@aol.com
    I know I m a language lawyer at times, but I am, so there. I m sure I have seen written any number of times on this news group: Don t add code unless you have
    Message 1 of 129 , Sep 18, 2000
    • 0 Attachment
      I know I'm a language lawyer at times, but I am, so there.
      I'm sure I have seen written any number of times on this news group:

      "Don't add code unless you have a broken test."
      and also
      "Refactor the code to get it into shape before adding new code."

      (Reminds me of Hunting of the Snark:
      <<Rule 42 of the code, "No one shall speak to the Man at the Helm,"
      had been completed by the Bellman himself with the words
      "and the Man at the Helm shall speak to no one."
      So remonstrance was impossible, and no steering could bedone till
      the next varnishing day.>>
      )

      Ron's suggestion would imply to
      write the test,
      watch it fail,
      remove the test,
      refactor the old code passing all the old tests until it looks ripe, then
      add the test back in,
      watch it fail,
      add the new code.


      Course, back in the old C3 days, reliable rumor reaches me, people used a
      different procedure:
      write the test
      watch it fail
      add new code (no refactoring, 'cuz see below)
      watch test pass
      refactor like blazes until code is shiny and passes tests
      (ergo, no refactoring needed next time)

      Running this all through my head, I get:
      a) As will all things, I suspect each person and team has their own variant.
      b) how much does it really matter?
      b) if one way is better, Kent will say, "Why do it any less than the best
      way?"
      c) whatever I say, Kent will say something different (unless I say he will,
      ...)
      .... so ??? ...


      Ron Jeffries:
      > You're right: it's not entirely good to do that. If you refactor with the
      > bar red, you can break something and then you have two broken tests.
      > Therefore, either:
      >
      > Case A:
      > 1. Write a test.
      > -> Get red.
      > 2. Make test run.
      > -> Get green.
      > 3. Refactor.
      > -> Stay green.
      >
      > Or
      >
      > Case B:
      > -> Be Green
      > 1. Refactor.
      > -> Stay green.
      > 2. Write new test.
      > -> Get red.
      > 3. Make test work.
      > -> Get green.
      >
      > Although certain senior XPers report refactoring before putting a feature
      > in, I suspect that the bulk of the time they refactor after making the
      test
      > run, i.e. Case A.


      Alistair Cockburn
      Humans and Technology

      7691 Dell Rd.
      Salt Lake City, UT 84121
      Work Phone: 801.947.9275
      Fax: 775.416.6457
      http://members.aol.com/acockburn
      write to: alistair.cockburn@...
    • 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.