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

Re: [XP] Refactoring legacy code

Expand Messages
  • Peter Schrier & Narda Bergsma
    Most times, bugs are detected in the UI by the end-users. So, to prove that the user is right about the bug, you have to write a Functional Test which reveals
    Message 1 of 28 , Sep 1, 2000
    • 0 Attachment
      Most times, bugs are detected in the UI by the end-users. So, to prove that the
      user is right about the bug, you have to write a Functional Test which reveals
      it. Then you have to track it down to your code, make a UnitTest for it and fix
      the code, UnitTest to make sure the bug is squashed, and FunctionalTest to
      prove that for the user the bug is removed as well.

      Peter Schrier

      Quoting Mark Wilden <mark@...>:

      > ----- Original Message -----
      > From: "Michael C. Feathers" <mfeathers@...>
      > >
      > > For every bug you fix, make sure it is reflected
      > > in a functional test and in a unit test.
      >
      > Of course, you write the test before you fix the bug. Also, I don't think
      > it's necessary to explicitly include detection of the bug in a functional
      > test, if a unit test already does it. It depends how massive and visible
      > the
      > bug is, I guess.
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > Ad-free courtesy of objectmentor.com
      >
      >
    • Robert Watkins
      ... I ve just been put on a project where the entire group (down to and including the admin assistants) upped and left in a couple of weeks. My biggest
      Message 2 of 28 , Sep 3, 2000
      • 0 Attachment
        Thomas O Matelich writes:
        > The biggest downside I see is that backfitting UT's is hard
        > enough, but putting in
        > FT's? Ouch. Of course, you could use non-automated FT's until
        > you have some sort of
        > framework set up I suppose.

        I've just been put on a project where the entire group (down to and
        including the admin assistants) upped and left in a couple of weeks. My
        biggest challenge right now (aside from getting my brain (which these days
        seems only as big as a reasonable sized moon) is convincing my PHB that we
        need to get some automated tests in. The current code seems reasonably
        stable (ie, the bug reports aren't drowning us), but it's organically grown
        code over 10 years, and we just can't say for sure what we break when we
        change things.

        As a first cut, what I want to do is come up with a bullet-list of the
        functionality, then take something like WinRunner and just record each
        interaction. If nothing else, we'll know that the program isn't GPFing. As
        we make changes, we'll extend the tests, and hopefully start putting in some
        code-level tests.

        (My personal saving grace here is that I'm in seagull mode... they're hiring
        new people, and once I get them trained up, I'm going back to my old
        project. Hopefully, I can test-infect the new guys quickly enough.)

        Robert.
      • John Carter
        ... Find the @%$#%@#! s that wrote / added to that 3000 line monstrosity and fire them straight away before they do _any_ more harm. Wack them over the head
        Message 3 of 28 , Sep 7, 2000
        • 0 Attachment
          On Thu, 31 Aug 2000, Michael Larionov wrote:

          > Our team was in exactly the same situation, and we did refactoring.
          > Unfortunately, the code was not really testable, because the methods
          > were very large ( one of them was 3000 lines!), so we did some
          > refactoring without unit testing and relied on acceptance tests
          > solely.

          Find the @%$#%@#!'s that wrote / added to that 3000 line monstrosity and
          fire them straight away before they do _any_ more harm.

          Wack them over the head with the a large stick for me, as they may be the
          very ones that left me with some of my problems.

          However it may not be quite as bad as it appears as these %$#%$#@! tend to
          be "copy and paste" programmers. ie. That 3000 lines is often a couple of
          segments copied and pasted time and time again with minor variants.


          John Carter

          Work Email : john@... Private email : cyent@...
          Yell Phone : 083-543-6915 Phone : 27-12-348-4246

          Carter's Compass...

          I know I'm on the right track when by deleting code I'm adding
          functionality.
        • John Carter
          ... Often the authors of such beasties haven t understood the notion of OOPS. They have these KLOC size classes. Break them up into much smaller classes and
          Message 4 of 28 , Sep 7, 2000
          • 0 Attachment
            On Wed, 30 Aug 2000, Rolf F. Katzenberger wrote:

            > assume several 100 KLOCs of bug-ridden legacy Java code, hardly any
            > unit tests; throwing away the code and rewriting the system from
            > scratch is not an option.
            >
            > What would you say would be the wisest strategy for "refactoring" in
            > this case? Can you refactor without writing tests first? What if the
            > code hasn't been written for testing?

            Often the authors of such beasties haven't understood the notion of OOPS.
            They have these KLOC size classes. Break them up into much smaller classes
            and unit test them first.

            Often such monsters are written by "copy-and-paste" programmers. So it
            isn't quite as bad as it appears. Find copy and paste patterns. And
            refactor them into methods. Often these patterns will be within a single
            monster method.

            Switch on every warning that the Java will give you. They like mini unit
            tests. Clear every warning first before you start.

            Read my .sig, it was developed in exactly that sort of environment.

            John Carter

            Work Email : john@... Private email : cyent@...
            Yell Phone : 083-543-6915 Phone : 27-12-348-4246

            Carter's Compass...

            I know I'm on the right track when by deleting code I'm adding
            functionality.
          Your message has been successfully submitted and would be delivered to recipients shortly.