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

Re: [XP] Code metrics as an input for refactoring?

Expand Messages
  • Chris Stevenson
    ... I ve used them (mostly coverage tools) on legacy systems to provide an input to refactoring, but I feel that to refactor just to driveup metrics is
    Message 1 of 5 , Sep 1, 2005
    • 0 Attachment
      > Has somebody explored the idea of using these metrics to justify
      > refactoring? Some of the senior managers just equate refactoring with
      > rework and wonder why we "didn't do it right the first time".

      I've used them (mostly coverage tools) on legacy systems to provide an
      input to refactoring, but I feel that to refactor just to driveup
      metrics is dangerous.

      On the legacy systems I have worked on, we used coverage to tell us
      where we need to improve testing before we work on an area of code,
      but we would only refactor to help with a new card.

      When I have refactored 'for the sake of it' in the past it has always
      caused problems. One time I remember we went on a refactoring binge
      and came up with a really clean design - that had to be changed
      completely for the next piece of real business functionality.

      Coverage and metrics are like that also. Remember that in Refactoring
      the book, for every refactoring, there is an equal and opposite
      refactoring - there is no guarantee that the one you choose based on
      metrics will be better than the one you choose based on a business
      need. Rather the opposite I would have thought.

      chris

      --

      Chris Stevenson
      ThoughtWorks Canada
    • William Pietri
      ... I ve certainly used metrics to look for things that might need to be cleaned up, but I don t follow them religiously. I find them more handy in unfamiliar
      Message 2 of 5 , Sep 1, 2005
      • 0 Attachment
        SherlockSridhar wrote:

        >Hello,
        >
        >Recently, there have been a number of tools coming up that seek to
        >measure design and code quality. Object oriented metrics as well as
        >complexity measures are reported by these tools.
        >
        >

        I've certainly used metrics to look for things that might need to be
        cleaned up, but I don't follow them religiously. I find them more handy
        in unfamiliar code bases than in ones where I'm comfortable.

        >Has somebody explored the idea of using these metrics to justify
        >refactoring? Some of the senior managers just equate refactoring with
        >rework and wonder why we "didn't do it right the first time".
        >
        >

        Wouldn't bad metrics just be proof to them that you didn't do it right
        the first time?

        Personally, I tackle that misconception directly. When they see new cars
        come out with design improvements, why don't they get upset that car
        designers didn't do it right the first time?

        William
      • William Wake
        ... There s certainly been some. Especially the simple metrics like classes sorted by number of lines or methods sorted by number of lines, can give you some
        Message 3 of 5 , Sep 2, 2005
        • 0 Attachment
          On 9/1/05, SherlockSridhar <sherlocksridhar@...> wrote:
          >
          > Has somebody explored the idea of using these metrics to justify
          > refactoring? Some of the senior managers just equate refactoring with
          > rework and wonder why we "didn't do it right the first time".

          There's certainly been some. Especially the simple metrics like classes
          sorted by number of lines or methods sorted by number of lines, can give you
          some indication of potential trouble spots. In my _Refactoring Workbook_,
          one of the early chapters is title "Measured Smells", working with problems
          like Long Method or Long Class.
          I have three problems though:
          1. Simple metrics can be gamed: the metric improves but the code does not.
          (For example, I saw someone deal with long methods by replacing it with
          routines that were called in any method longer than 5 lines. It didn't help
          coherence, didn't raise the level of abstraction, but it met the metric.)
          2. Subtle metrics may have their place but they require interpretation. And
          they often don't seem to catch the real problems. And I don't expect them to
          - they only have a view of the code syntax/semantics - not of the picture
          the code creates in the reader, and no understanding of what the code "could
          be". The metric won't tell me that "Transaction" is a better name than
          "Purchase" - or vice versa, depending on the context.
          I have to add that I had a class in college that had us go back to the key
          metrics papers and re-analyze some of their data. What I saw didn't inspire
          my confidence in the significance of the results. I think there's some
          "there" there but I don't sweat it too much. (What I do in practice is
          occasionally do a check of class sizes and test coverage.)
          As for "refactoring is rework", it may or may not be true in any given
          case. If a team told me they had many classes with 500+ lines, or they
          needed to stop accepting stories and go refactor for a couple months (or a
          year!), I'd be inclined to suspect it's rework (going back to work that
          could/should have been done better the first time around). If it's built in
          as an ongoing part of development (as spell-checking, grammar-checking, and
          editing are part of writing), I'd be less inclined to look at it that way.
          --
          Bill Wake William.Wake@... www.xp123.com <http://www.xp123.com>
          Author of "Refactoring Workbook"


          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.