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

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

Expand Messages
  • 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 1 of 5 , Sep 2, 2005
      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.