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

Re: [XP] When to refactor?

Expand Messages
  • J. B. Rainsberger
    ... In other words, there are two kinds of refactorings: * generally-accepted-to-be-good-in-most-situations refactorings * only-important-for-the-next-story
    Message 1 of 72 , Sep 1, 2005
    • 0 Attachment
      Ron Jeffries wrote:
      > On Wednesday, August 31, 2005, at 10:06:02 AM, J. B. Rainsberger wrote:
      >
      >
      >>>Definitely. I generally recommend refactoring /only/ in the presence
      >>>of a story. Improve the design where it needs it now: To refactor
      >>>code that isn't currently the target of a story is classical YAGNI.
      >
      >
      >>I wonder about this. If our codebase isn't well-factored, then how can
      >>we claim to keep the cost of change low? Part of the evolutionary design
      >>pitch is "We don't prepare for any particular kind of change; we can
      >>handle any kind of change without prohibitive expense." If we tend to
      >>refactor only in the presence of the next story, then how can that
      >>statement be true?
      >
      >
      > I'm pretty sure about this one, and would expect that we could
      > reach a common understanding and agreement, perhaps after one or
      > both of us picks up on the other person's idea. I hope it's both, or
      > failing that, me, who learns.
      >
      > I see it this way ...
      >
      > The return on a refactoring investment comes to us when we put a
      > change into code that is ready for that change.
      >
      > If we have some code in the system that is unready for change, it's
      > doing no current harm. Improving it, conversely, will do no good --
      > unless and until we have a story that needs that code to be better.
      >
      > Therefore ... it seems to me after much reflection ... we should
      > /keep/ the code clean, but if we learn after commit that it's not as
      > clean as we'd like, our best move is to clean it up right before we
      > /need/ it to be clean, namely when we have a story that wants to be
      > put in there?
      >
      > Does that clarify? Do we agree yet?

      In other words, there are two kinds of refactorings:

      * generally-accepted-to-be-good-in-most-situations refactorings
      * only-important-for-the-next-story refactorings

      Things like renaming to good names, extracting to composed methods,
      extracting to follow the SRP are all in the first category. We do them
      because they're good basic hygiene.

      The other category includes refactoring to Strategy because it would
      make /that/ easier to do, or extracting /this/ method because /that/
      feature wants to override it. We do these only when a story demands it,
      because otherwise they are highly speculative without the presence of a
      story.

      Is that what you mean? I'll write a cheque for that.
      --
      J. B. (Joe) Rainsberger
      Diaspar Software Services
      http://www.diasparsoftware.com
      2005 Gordon Pask Award Winner for contribution to Agile practice
      Author, JUnit Recipes: Practical Methods for Programmer Testing
    • Uberto Barbini
      ... mauve ... Yes, we ask and write it down. Anyway they don t ask never the same thing again. They have enough imagination! ;)) Bye Uberto
      Message 72 of 72 , Sep 2, 2005
      • 0 Attachment
        > I ask the customer to ask himself, "What's the good business reason for
        > doing this?" Of course, he already knows to do this, but I want to get
        > at the business reason for such a request, so we can write the story
        > that way. This saves us from later asking, "Why did I want this in
        mauve
        > again?!"

        Yes, we ask and write it down. Anyway they don't ask never the same
        thing again. They have enough imagination! ;))

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