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

Refactoring legacy code

Expand Messages
  • Rolf F. Katzenberger
    Hi: 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
    Message 1 of 28 , Aug 30, 2000
    • 0 Attachment
      Hi:

      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?

      I'm looking forward to your answers...

      Best regards,
      Rolf

      --
      ______________________________________________________________________
      Rolf F. Katzenberger | Consultant | Trainer 2000-05-05
      Home: http://www.geocities.com/SiliconValley/Park/9557
      PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F
    • Russel Hill
      ... Ouch.. been there done that. not in Java though... ... Short answer: no. Longer answer: Yes you can, but I wouldn t recommend it. You don t have to
      Message 2 of 28 , Aug 30, 2000
      • 0 Attachment
        At 06:35 PM 8/30/00 +0200, you wrote:
        >Hi:
        >
        >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.

        Ouch.. been there done that. not in Java though...

        >What would you say would be the wisest strategy for "refactoring" in
        >this case? Can you refactor without writing tests first?

        Short answer: no.

        Longer answer: Yes you can, but I wouldn't recommend it.

        You don't have to refactor the entire thing... pick either the worst stuff
        or the stuff you have to work on next (could be the same stuff)... invent
        tests for that.

        >What if the
        >code hasn't been written for testing?

        Sometimes you get inventive with your testing strategy...

        Sometimes you bite the bullet and do some minimal refactoring to allow
        testing.

        If there are pieces for which you can't do any of the above... consider
        throwing out that piece, writing tests then coding what you need to make
        the tests pass.


        >I'm looking forward to your answers...
        >
        >Best regards,
        >Rolf
        >
        >--
        >______________________________________________________________________
        >Rolf F. Katzenberger | Consultant | Trainer 2000-05-05
        >Home: http://www.geocities.com/SiliconValley/Park/9557
        >PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F
        >
        >To Post a message, send it to: extremeprogramming@...
        >
        >To Unsubscribe, send a blank message to:
        >extremeprogramming-unsubscribe@...
        >
        >Ad-free courtesy of objectmentor.com
      • Morris, Chris
        ... As you go in to make changes, fix bugs, refactor the code you re changing and unit test as you go. It s a slow climb out of the hole - but some progress
        Message 3 of 28 , Aug 30, 2000
        • 0 Attachment
          > 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?

          As you go in to make changes, fix bugs, refactor the code you're changing
          and unit test as you go. It's a slow climb out of the hole - but some
          progress out is better than staying put.

          Chris
        • Joshua Macy/Towers Perrin
          Customer writes a story about removing a bug. Write a test that demonstrates the bug. Fix the bug. Refactor the fixed code. Rinse. Repeat. Basically, you can t
          Message 4 of 28 , Aug 30, 2000
          • 0 Attachment
            Customer writes a story about removing a bug.
            Write a test that demonstrates the bug.
            Fix the bug.
            Refactor the fixed code.
            Rinse.
            Repeat.

            Basically, you can't retrofit unit tests all at once, but any unit test you add
            will improve the situation. Sometimes you might have to prime the pump with a
            small refactoring that permits you to write your first unit test, but the
            strategy is to gradually whittle away at the un-tested/testable code, starting
            with the code that actually gives the customer the most problems until either
            you have unit tests for everything and have refactored it or there's no further
            economic justification for improving the code (the customer has higher
            priorities than the remaining bugs).





            "Rolf F. Katzenberger" <rfk@...> on 08/30/2000 12:35:44 PM

            Please respond to extremeprogramming@egroups.com


            To: extremeprogramming@egroups.com
            cc: (bcc: Joshua Macy/Towers Perrin)
            From: "Rolf F. Katzenberger" <rfk@...>
            Date: 08/30/2000 12:35 PM
            Subject: [XP] Refactoring legacy code



            Hi:

            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?

            I'm looking forward to your answers...

            Best regards,
            Rolf

            --
            ______________________________________________________________________
            Rolf F. Katzenberger | Consultant | Trainer 2000-05-05
            Home: http://www.geocities.com/SiliconValley/Park/9557
            PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F

            To Post a message, send it to: extremeprogramming@...

            To Unsubscribe, send a blank message to:
            extremeprogramming-unsubscribe@...

            Ad-free courtesy of objectmentor.com
          • Mark Wilden
            ... From: Rolf F. Katzenberger ... Are there any tests at all? Functional tests? Are there any QA staff on board? In other words, if you make a
            Message 5 of 28 , Aug 30, 2000
            • 0 Attachment
              ----- Original Message -----
              From: "Rolf F. Katzenberger" <rfk@...>
              >
              > 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?

              Are there any tests at all? Functional tests? Are there any QA staff on
              board?

              In other words, if you make a change to the code, is there any way you can
              tell if the change worked?

              If there is, I'd start by factoring out duplicated code. That's usually
              pretty safe.
            • Michael C. Feathers
              ... From: Rolf F. Katzenberger ... The first question I have is: who is commissioning the refactoring? Is it you? Because you need to add new
              Message 6 of 28 , Aug 30, 2000
              • 0 Attachment
                ----- Original Message -----
                From: Rolf F. Katzenberger <rfk@...>
                > 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?

                The first question I have is: who is "commissioning" the
                refactoring? Is it you? Because you need to add
                new features?

                If that is the case, and you are convinced that
                you really want to work on that project, you
                have a couple of choices. The one everyone
                recommends is to write tests for the areas
                that you need to modify as you modify them.
                Another technique, a true last resort, is to perform
                mini-"substitutions."

                That is, find a chunk of poor code,
                build up its replacement in a test harness,
                inject it into the project to run in parallel
                with the poorly structured code. Compare
                results. When you are convinced that the
                new code does what the old code does,
                remove the old code.

                There is a lot of risk involved. Like an
                organ transplant, it may succeed or fail and
                a convincing failure may take a while.

                If you do it, do it in very small pieces.
                If the code is as buggy as you say,
                people may not notice that you are
                silently rewriting the system from the
                inside.

                Refactoring in place is usually the
                better choice, but when on life-support..


                Michael

                ---------------------------------------------------
                Michael Feathers mfeathers@...
                Object Mentor Inc. www.objectmentor.com
                Training/Mentoring/Development
                -----------------------------------------------------
                "Only puny secrets need protection.
                Big discoveries are protected by
                public incredulity." --MarshallMcLuhan
              • Ron Jeffries
                ... I can, but when I m done I don t know whether the refactoring worked. In bug-ridden code, there are usually lots of traps I don t know about and don t see.
                Message 7 of 28 , Aug 30, 2000
                • 0 Attachment
                  At 06:35 PM 8/30/00 +0200, 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?

                  I can, but when I'm done I don't know whether the refactoring worked. In
                  bug-ridden code, there are usually lots of traps I don't know about and
                  don't see. So when I refactor, I make mistakes, making the code even more
                  bug-ridden.

                  On projects where what they want is more bug-ridden code, it's kind of a
                  fun way to work. If they actually want the software to get better, I need
                  to write tests before I refactor. Someone smarter might be able to do
                  better without the tests. My brain is only as big as a [very small] planet. ;->

                  Ronald E Jeffries
                  http://www.XProgramming.com
                  http://www.objectmentor.com
                • Rolf F. Katzenberger
                  Hi Mark, On Wed, 30 Aug 2000 11:15:36 -0700, Mark Wilden ... Hardly worth mentioning. ... Not at all. ... No. ... IMHO only if tests are
                  Message 8 of 28 , Aug 30, 2000
                  • 0 Attachment
                    Hi Mark,

                    On Wed, 30 Aug 2000 11:15:36 -0700, "Mark Wilden" <mark@...>
                    wrote:

                    >----- Original Message -----
                    >From: "Rolf F. Katzenberger" <rfk@...>
                    >>
                    >> 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?
                    >
                    >Are there any tests at all?

                    Hardly worth mentioning.

                    > Functional tests?

                    Not at all.

                    > Are there any QA staff on
                    >board?

                    No.

                    >In other words, if you make a change to the code, is there any way you can
                    >tell if the change worked?

                    IMHO only if tests are added while progressing, as suggested by
                    others.

                    >If there is, I'd start by factoring out duplicated code. That's usually
                    >pretty safe.

                    Sounds reasonable!

                    Best regards,
                    Rolf


                    --
                    ______________________________________________________________________
                    Rolf F. Katzenberger | Consultant | Trainer 2000-05-05
                    Home: http://www.geocities.com/SiliconValley/Park/9557
                    PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F
                  • Rolf F. Katzenberger
                    Hi Michael, On Wed, 30 Aug 2000 13:49:37 -0500, Michael C. Feathers ... The customer is driven mad by bugs. That s why. [snip; on mini-substitutions:] ...
                    Message 9 of 28 , Aug 30, 2000
                    • 0 Attachment
                      Hi Michael,

                      On Wed, 30 Aug 2000 13:49:37 -0500, "Michael C. Feathers"
                      <mfeathers@...> wrote:

                      >----- Original Message -----
                      >From: Rolf F. Katzenberger <rfk@...>
                      >> 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?
                      >
                      >The first question I have is: who is "commissioning" the
                      >refactoring? Is it you? Because you need to add
                      >new features?

                      The customer is driven mad by bugs. That's why.

                      [snip; on mini-substitutions:]
                      >That is, find a chunk of poor code,
                      >build up its replacement in a test harness,
                      >inject it into the project to run in parallel
                      >with the poorly structured code. Compare
                      >results. When you are convinced that the
                      >new code does what the old code does,
                      >remove the old code.
                      >
                      >There is a lot of risk involved. Like an
                      >organ transplant, it may succeed or fail and
                      >a convincing failure may take a while.
                      >
                      >If you do it, do it in very small pieces.
                      >If the code is as buggy as you say,
                      >people may not notice that you are
                      >silently rewriting the system from the
                      >inside.

                      Actually, I won't be rewriting it. It is them. I just sit back and
                      watch ;-)


                      Best regards,
                      Rolf

                      --
                      ______________________________________________________________________
                      Rolf F. Katzenberger | Consultant | Trainer 2000-05-05
                      Home: http://www.geocities.com/SiliconValley/Park/9557
                      PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F
                    • Rolf F. Katzenberger
                      Hi Ron, On Wed, 30 Aug 2000 16:49:25 -0400, Ron Jeffries wrote: [snip] ... Ok. Where does one start if one has several 100 KLOCs? Would
                      Message 10 of 28 , Aug 30, 2000
                      • 0 Attachment
                        Hi Ron,

                        On Wed, 30 Aug 2000 16:49:25 -0400, Ron Jeffries <ronjeffries@...>
                        wrote:

                        [snip]
                        > If they actually want the software to get better, I need
                        >to write tests before I refactor. Someone smarter might be able to do
                        >better without the tests. My brain is only as big as a [very small] planet. ;->

                        Ok. Where does one start if one has several 100 KLOCs? Would you write
                        "all" tests in advance, before you change a line of code?

                        Best regards,
                        Rolf

                        --
                        Rolf F. Katzenberger (rkatzenberger@...)
                        Team Lead

                        BEANS AG
                        Muenchener Str. 15a
                        D-82319 Starnberg
                        Germany
                        Phone (+49) 8151 36 84 - 317
                        Fax (+49) 8151 36 84 - 349
                      • Lea
                        ... All the tests? This is *not* how I understand XP to be used (see one, do one, teach one... ) You have a legacy system. You have a change on it being
                        Message 11 of 28 , Aug 31, 2000
                        • 0 Attachment
                          Rolf F. Katzenberger wrote:
                          > Ok. Where does one start if one has several 100 KLOCs? Would you write
                          > "all" tests in advance, before you change a line of code?

                          All the tests? This is *not* how I understand XP to be used (see one,
                          do one, teach one... <g>)
                          You have a legacy system.
                          You have a change on it being made *today*
                          Dont worry about the whole system, worry about the change you have to
                          do today; approach it in an XP fashion:
                          Assume a bug report - write a test which fails in the manner reported
                          in the bug.
                          Then fix the bug.
                          Voila! Test passes.
                          You have your first unit test.
                          And a handle on the code and how it can be refactored.
                          Maybe you have some budget for refactoring the code; now would be when
                          I would use some of that to improve the bits I just worked on.
                          Starting by writing unit tests for what it does that pass (presumably
                          <g>), then refactoring and this not being complete until the new unit
                          tests pass again.

                          Am I on the right track?

                          --
                          Lea mailto:leal@...
                        • Ron Jeffries
                          ... That would be one way ... can you think of another? Ronald E Jeffries http://www.XProgramming.com http://www.objectmentor.com
                          Message 12 of 28 , Aug 31, 2000
                          • 0 Attachment
                            At 08:30 AM 8/31/00 +0200, Rolf F. Katzenberger wrote:
                            >Ok. Where does one start if one has several 100 KLOCs? Would you write
                            >"all" tests in advance, before you change a line of code?

                            That would be one way ... can you think of another?

                            Ronald E Jeffries
                            http://www.XProgramming.com
                            http://www.objectmentor.com
                          • Ron Jeffries
                            ... Oh yes. One detail: After writing the first test that shows the bug, how would you be sure you hadn t broken something else? Ronald E Jeffries
                            Message 13 of 28 , Aug 31, 2000
                            • 0 Attachment
                              At 06:42 PM 8/31/00 +0930, Lea wrote:
                              >Assume a bug report - write a test which fails in the manner reported
                              >in the bug.
                              >Then fix the bug.
                              >Voila! Test passes.
                              >You have your first unit test.
                              >And a handle on the code and how it can be refactored.
                              >Maybe you have some budget for refactoring the code; now would be when
                              >I would use some of that to improve the bits I just worked on.
                              >Starting by writing unit tests for what it does that pass (presumably
                              ><g>), then refactoring and this not being complete until the new unit
                              >tests pass again.
                              >
                              >Am I on the right track?

                              Oh yes. One detail: After writing the first test that shows the bug, how
                              would you be sure you hadn't broken something else?



                              Ronald E Jeffries
                              http://www.XProgramming.com
                              http://www.objectmentor.com
                            • Arrizza, John
                              ... It depends on what you want to do. If you d like to take the YAGNI and DTSTTWW (or whatever the #$%^ acronym is) approach to this then do only what you
                              Message 14 of 28 , Aug 31, 2000
                              • 0 Attachment
                                > -----Original Message-----
                                > From: Rolf F. Katzenberger [mailto:rfk@...]
                                > 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?

                                It depends on what you want to do. If you'd like to take the YAGNI and
                                DTSTTWW (or whatever the #$%^ acronym is) approach to this then do only what
                                you have to do now.

                                Then the process will be something like this:
                                - do not write unit tests across the board.
                                - if you find a bug in the system, fix it and keep track of where it is.
                                - if you have to fix another bug in the same part of the code, add unit
                                tests around that area using the "test anything that could possibly break"
                                idea. Refactor as best you can around the classes that are tested.

                                If you want to get a little less strict: before you fix a bug, write a
                                functional test that fails because of that bug. Fix the bug. rerun the FT to
                                ensure the bug has gone away and the FT succeeds.

                                This will get you UTs (and FTs) around those parts of the system that are
                                the worst offenders. Future bugs will get easier and easier to fix and they
                                won't come back because of the UTs (and FTs).

                                That's it.

                                John
                              • Lea
                                ... You wouldnt know... but you wouldnt have known the old way, either, so you dont lose any points... As the unit tests accumulate over time you would,
                                Message 15 of 28 , Aug 31, 2000
                                • 0 Attachment
                                  > At 06:42 PM 8/31/00 +0930, Lea wrote:
                                  >>Assume a bug report - write a test which fails in the manner reported
                                  >>in the bug.
                                  >>Then fix the bug.
                                  >>Voila! Test passes.
                                  >>You have your first unit test.
                                  >>And a handle on the code and how it can be refactored.
                                  >>Maybe you have some budget for refactoring the code; now would be when
                                  >>I would use some of that to improve the bits I just worked on.
                                  >>Starting by writing unit tests for what it does that pass (presumably
                                  >><g>), then refactoring and this not being complete until the new unit
                                  >>tests pass again.
                                  >>
                                  >>Am I on the right track?

                                  Ron Jeffries wrote:
                                  > Oh yes. One detail: After writing the first test that shows the bug, how
                                  > would you be sure you hadn't broken something else?

                                  You wouldnt know... but you wouldnt have known the old way, either, so
                                  you dont lose any points...

                                  As the unit tests accumulate over time you would, though...

                                  --
                                  Lea mailto:leal@...
                                  ~ by george, I think I've got it.
                                  Pity the project got cance^h^h^h deferred last week.
                                  But XP doesnt map very well to MIL-STD 498 anyway...
                                  Next project, please!
                                • theodore.scott@prometric.com
                                  ... Back in the early days of the U.S., Alexander Hamilton was the Secretary of the Treasury and Andrew Jackson was President. LeEnfant (the planner of W.D.C.)
                                  Message 16 of 28 , Aug 31, 2000
                                  • 0 Attachment
                                    Rolf said:
                                    >Ok. Where does one start if one has several 100 KLOCs?

                                    Back in the early days of the U.S., Alexander Hamilton was the Secretary
                                    of the Treasury and Andrew Jackson was President. LeEnfant (the planner
                                    of W.D.C.) hadn't identified a site for the Treasury building and Hamilton
                                    was worried and went to Jackson. Jackson put on his jacket and picked up
                                    a walking stick and took Hamilton out of the White House to a hill several
                                    hundred yards away. He drove his walking stick in the ground and said
                                    put it there, Hamilton. You still have to go around the Treasury Building
                                    because it was sited blocking planned streets.

                                    What does this have to do with where to start? Pick a spot and start.
                                    I might tend to choose one where I would be working on a bug anyway,
                                    since bugs tend to cluster up in sections of code. Now moving the
                                    Treasury building would be too expensive a refactoring to do, so I'd
                                    make sure that I wasn't taking that on also.

                                    >Would you write "all" tests in advance, before you change a line of code?

                                    Certainly not. I would write the tests I need to support the piece
                                    I'm working on at the moment, and trust that I will get to the rest
                                    later.


                                    -Ted
                                  • Rolf F. Katzenberger
                                    On Thu, 31 Aug 2000 07:14:57 -0400, Ron Jeffries ... How about - closing classes first, by making as many things private as possible -
                                    Message 17 of 28 , Aug 31, 2000
                                    • 0 Attachment
                                      On Thu, 31 Aug 2000 07:14:57 -0400, Ron Jeffries <ronjeffries@...>
                                      wrote:

                                      >At 08:30 AM 8/31/00 +0200, Rolf F. Katzenberger wrote:
                                      >>Ok. Where does one start if one has several 100 KLOCs? Would you write
                                      >>"all" tests in advance, before you change a line of code?
                                      >
                                      >That would be one way ... can you think of another?

                                      How about

                                      - "closing" classes first, by making as many things
                                      private as possible
                                      - reducing redundant code (as suggested in this thread)
                                      - adding tests as one proceeds, to avoid writing
                                      tests in advance for things that you will throw out anyway


                                      Regards,
                                      Rolf

                                      --
                                      ______________________________________________________________________
                                      Rolf F. Katzenberger | Consultant | Trainer 2000-05-05
                                      Home: http://www.geocities.com/SiliconValley/Park/9557
                                      PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F
                                    • Rolf F. Katzenberger
                                      On Thu, 31 Aug 2000 08:34:24 -0400, Arrizza, John ... The idea of starting with functional tests (a top down approach, in the end) sounds promising. It
                                      Message 18 of 28 , Aug 31, 2000
                                      • 0 Attachment
                                        On Thu, 31 Aug 2000 08:34:24 -0400, "Arrizza, John"
                                        <john.arrizza@...> wrote:

                                        >If you want to get a little less strict: before you fix a bug, write a
                                        >functional test that fails because of that bug. Fix the bug. rerun the FT to
                                        >ensure the bug has gone away and the FT succeeds.

                                        The idea of starting with functional tests (a top down approach, in
                                        the end) sounds promising. It reliefs one of thinking in terms of
                                        entangled code only.

                                        Regards,
                                        Rolf

                                        --
                                        Rolf F. Katzenberger (rkatzenberger@...)
                                        Team Lead

                                        BEANS AG
                                        Muenchener Str. 15a
                                        D-82319 Starnberg
                                        Germany
                                        Phone (+49) 8151 36 84 - 317
                                        Fax (+49) 8151 36 84 - 349
                                      • Michael C. Feathers
                                        ... From: Rolf F. Katzenberger ... I was thinking about something like that one too. For every bug you fix, make sure it is reflected in a
                                        Message 19 of 28 , Aug 31, 2000
                                        • 0 Attachment
                                          ----- Original Message -----
                                          From: Rolf F. Katzenberger <rfk@...>
                                          > The idea of starting with functional tests (a top down approach, in
                                          > the end) sounds promising. It reliefs one of thinking in terms of
                                          > entangled code only.

                                          I was thinking about something like that one too.
                                          For every bug you fix, make sure it is reflected
                                          in a functional test and in a unit test. Keep the
                                          structure more or less the same until the bugs
                                          evaporate, at that point you have a decent
                                          invariant that lets you improve structure.

                                          I haven't tried that though. Anyone see
                                          a downside?


                                          Michael

                                          ---------------------------------------------------
                                          Michael Feathers mfeathers@...
                                          Object Mentor Inc. www.objectmentor.com
                                          Training/Mentoring/Development
                                          -----------------------------------------------------
                                          "Only puny secrets need protection.
                                          Big discoveries are protected by
                                          public incredulity." --MarshallMcLuhan


                                          >
                                          > Regards,
                                          > Rolf
                                          >
                                          > --
                                          > Rolf F. Katzenberger (rkatzenberger@...)
                                          > Team Lead
                                          >
                                          > BEANS AG
                                          > Muenchener Str. 15a
                                          > D-82319 Starnberg
                                          > Germany
                                          > Phone (+49) 8151 36 84 - 317
                                          > Fax (+49) 8151 36 84 - 349
                                          >
                                          > To Post a message, send it to: extremeprogramming@...
                                          >
                                          > To Unsubscribe, send a blank message to:
                                          extremeprogramming-unsubscribe@...
                                          >
                                          > Ad-free courtesy of objectmentor.com
                                        • Mark Wilden
                                          ... From: Michael C. Feathers ... Of course, you write the test before you fix the bug. Also, I don t think it s necessary to
                                          Message 20 of 28 , Aug 31, 2000
                                          • 0 Attachment
                                            ----- 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.
                                          • Arrizza, John
                                            ... The situation that the FT is supposed to handle is when a method has a subtle side-effect which other classes depend on. You may fix the bug and have the
                                            Message 21 of 28 , Aug 31, 2000
                                            • 0 Attachment
                                              > -----Original Message-----
                                              > From: Mark Wilden [mailto:mark@...]
                                              > 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.

                                              The situation that the FT is supposed to handle is when a method has a
                                              "subtle" side-effect which other classes depend on. You may fix the bug and
                                              have the UT succeed, but another class far far away fails. If that far away
                                              class fails in QA, you are lucky, but still strapped with fixing a confusing
                                              "new" bug. But if you are unlucky, it fails out in the field, once in a blue
                                              moon, or during a tradeshow, demo to the vencap armanis, etc.

                                              For example, the following code has a bug, it is supposed to return -2 not
                                              -1.

                                              int fn(int x)
                                              {
                                              int y;
                                              if (x == 3)
                                              return y;
                                              return -1;
                                              }

                                              I write the UT, notice that y is not initialized and change it to:

                                              int fn(int x)
                                              {
                                              int y = 0;
                                              if (x == 3)
                                              return y;
                                              return -2;
                                              }

                                              The UT runs green now. BUT, another class depended on fn(6) returning a
                                              non-zero value. The original code did return non-zero almost all the time
                                              (except for some annoying one-time bugs we've never really tracked down).
                                              And now it returns 0. If we're lucky the other class is frequently called
                                              and so we'd see this "new" bug manifest itself immediately. If not, oh well.

                                              This effect can occur by just refactoring the code. For instance,

                                              int fn(int x)
                                              {
                                              int y;
                                              if (x == 3)
                                              return y;
                                              return -1;
                                              }

                                              is refactored into:
                                              int fn(int x)
                                              {
                                              if (x == 3)
                                              return aSpecialValueForY();
                                              return -1;
                                              }

                                              int aSpecialValueForY()
                                              {
                                              return 0;
                                              }

                                              OTOH, what FT are you going to write? To be really sure that a fix will not
                                              break anything else, you need relatively good coverage of the entire calling
                                              tree of the method you are about to fix. Since that is against YAGNI (more
                                              or less), don't do the system-wide FTs and live with the risk. OTOH, to
                                              mitigate that risk, write an FT to highlight the bug and hope that the FT
                                              covers the area around the bug.

                                              John
                                            • Thomas Matelich
                                              ... 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
                                              Message 22 of 28 , Aug 31, 2000
                                              • 0 Attachment
                                                "Michael C. Feathers" wrote:

                                                > ----- Original Message -----
                                                > From: Rolf F. Katzenberger <rfk@...>
                                                > > The idea of starting with functional tests (a top down approach, in
                                                > > the end) sounds promising. It reliefs one of thinking in terms of
                                                > > entangled code only.
                                                >
                                                > I was thinking about something like that one too.
                                                > For every bug you fix, make sure it is reflected
                                                > in a functional test and in a unit test. Keep the
                                                > structure more or less the same until the bugs
                                                > evaporate, at that point you have a decent
                                                > invariant that lets you improve structure.
                                                >
                                                > I haven't tried that though. Anyone see
                                                > a downside?

                                                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.

                                                --
                                                Thomas O Matelich
                                                Senior Software Designer
                                                Zetec, Inc.
                                                sosedada@...
                                                tmatelich@...
                                              • Michael Larionov
                                                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
                                                Message 23 of 28 , Aug 31, 2000
                                                • 0 Attachment
                                                  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.

                                                  "Rolf F. Katzenberger" wrote:

                                                  Hi:

                                                  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?

                                                  I'm looking forward to your answers...

                                                  Best regards,
                                                  Rolf

                                                  --
                                                  ______________________________________________________________________
                                                  Rolf F. Katzenberger | Consultant | Trainer                 2000-05-05
                                                  Home: http://www.geocities.com/SiliconValley/Park/9557
                                                  PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F

                                                  To Post a message, send it to:   extremeprogramming@...

                                                  To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

                                                  Ad-free courtesy of objectmentor.com

                                                • Jim Little
                                                  From: Rolf F. Katzenberger ... planet. ;- ... Rolf, I *highly* recommend that you put smoke tests in place before you touch a line of code.
                                                  Message 24 of 28 , Aug 31, 2000
                                                  • 0 Attachment
                                                    From: "Rolf F. Katzenberger" <rfk@...>
                                                    > On Wed, 30 Aug 2000 16:49:25 -0400, Ron Jeffries <ronjeffries@...>
                                                    > wrote:
                                                    >
                                                    > > If they actually want the software to get better, I need
                                                    > >to write tests before I refactor. Someone smarter might be able to do
                                                    > >better without the tests. My brain is only as big as a [very small]
                                                    planet. ;->
                                                    >
                                                    > Ok. Where does one start if one has several 100 KLOCs? Would you write
                                                    > "all" tests in advance, before you change a line of code?

                                                    Rolf, I *highly* recommend that you put "smoke tests" in place before you
                                                    touch a line of code. Then add functional tests as you touch each feature,
                                                    and unit tests as you touch each method.

                                                    By "smoke test," I mean tests that prove that the critical parts of the
                                                    application still work. Find out from the customer what parts of the system
                                                    absolutely, positively, have to be there tomorrow, and write functional
                                                    tests for those features. Then run these smoke tests regularly.

                                                    In one particularly hairy refactoring (I was trying to refactor gcc for
                                                    various twisted reasons) I put the smoke tests directly into the makefile.
                                                    Every time the smoke tests passed, the script backed up all of the source
                                                    code, and backed up the previous backup. That saved my bacon many times.
                                                    If the smoke tests hadn't been in place, I would have had to throw away all
                                                    my refactorings and start over several times. Your code may not be quite
                                                    as... interesting, so such extreme measures might not be warranted. :)

                                                    As an example of what I mean by a "smoke test," my gcc smoke test compiled a
                                                    simple "hello world" program and compared the resulting output byte-for-byte
                                                    with gcc's original output. If I had been serious about the refactoring
                                                    (i.e., if money had been involved), I would have used a much more extensive
                                                    suite of programs.

                                                    Jim
                                                  • 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 25 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 26 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 27 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 28 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.