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

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

Expand Messages
  • Willem Bogaerts
    After reading the FAMOOS reengineering handbook, I decided to explore some simple metrics for Visual Basic Programs. I have written an aplication that shows
    Message 1 of 5 , Sep 1, 2005
      After reading the FAMOOS reengineering handbook, I decided to explore
      some simple metrics for Visual Basic Programs. I have written an
      aplication that shows the Lines-Of-Code for each routine and its
      complexity, along with the number of parameters as the dot size. I found
      it a nice tool to have for legacy applications, as you can "smell" the
      worst routines quickly. For projects that you are familiar with, the
      metrics application did not ad much to the id-dept code I already had of
      the code.
      I did show some of the generated diagrams to my manager. But I think I
      could have convinced him of the necessity of rework without the
      diagrams. The code was so forged out (the flexibility was beaten out of
      it by rapid changing requirements and patch-upon-patch programming) that
      rework was necessary. At that time I discovered the refactoring book,
      and my manager was glad it could be done in a controlled way.

      In our case, the answer was obvious. lots of the code WAS done right the
      first time (at least, they believed it and it was not that far beside
      the truth), but lots of decree-style requirements, no, demands, had
      transformed it into a heap of repairs.

      In many applications, you can do it the first time right, but "right"
      can also change.

      Best regards,
      Willem Bogaerts

      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.
      >
      > 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".
      >
      > Regards
      > Sherlocksridhar
      >
    • 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 2 of 5 , Sep 1, 2005
        > 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 3 of 5 , Sep 1, 2005
          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 4 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.