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

Code metrics as an input for refactoring?

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

      --
      http://www.fastmail.fm - A fast, anti-spam email service.
    • 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 2 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 3 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 4 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 5 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.