In a sense refactoring is just moving chunks of code around - sometimes combining chunks, sometimes spliting them. No matter how you cut it, the process you have described is refactoring rather than rewriting. Also in a sense refactoring is all about architecture. When you refactor you are rearchitecting some part of your "design". However, labels don't help you achieve your goal.

Database stuff I don't know much about. However if you take a representative snapshot of your databases that you can work with offline, then you can generate a test framework first against the databases and the code that services them. Then rework the code and databases into the new architecture (developing porting tools as needed along the way), remebering to check against the test framework. If you need to change the live system, make sure anything pertinent is checked by the common test framework and that the reworked system is updated to pass the new tests. Then when the reworked system is deemed ready and passes all tests you can quickly and confidently move the changes back into the live system. So long as both the live system and the reworked system behave as expected against the test framework at the time of the merge every thing should go smoothly.

The two key elements are identifying and implementing interfaces and implementing test frameworks against those interfaces. Once the interfaces are in place you can mix and match client and server code (code on either side of the interface) as you like. To the client code it doesn't matter how the server code does its job and it doesn't matter if it is in the same process, a different process on the same cpu, or a process running on hardware across the other side of the Earth.

Interfaces to provide isolation. Tests to make sure you don't break stuff. It really doesn't matter what you call it.

I think I'm starting to understand what you are saying. The key term that is still sound vague for me is interface. My understanding of it is: interface is a small application that initially uses the code that I want to modify, which then changed to use the new code when the new code is ready. Hmmm. So I need to tests the behaviour of the interface instead of the code I want to change. Is that correct?

This is Brilliant!!! Pure Genius!!! This way I can be 99% sure that the new code behaves like the old code and that confirmation comes from the exact same test while I can significantly change the code. Thank you GrandFather. I wouldn't think of it myself. ++ for you. I guess I have to read up a lot more about refactoring technique.

Thank you

-cheepy-

Very nearly correct. An interface is a defined way for one piece of code to interact with another. Your code is already using interfaces informally - every module you use is accessed through an interface: the stuff it makes public.

The trick here is to define the interfaces that you need and to write tests against those interfaces. Defining interfaces allows you to partition the code off so that things can be worked on independently on either side of the partition without. And yes, the benefit is exactly as you describe.

The initial hard work is identifying where formal interfaces are required and implementing them. The implementation should be fairly light weight and should be a simple matter of writing a new module for each interface that receives calls from the old "client" code and passes those calls through to the old "server" code. Here "client" is simply the calling code and "server" is the called code. The intent is to emphasise the point that there are two sides to the interface. The interface itself is just a line drawn in the sand. The temporary module I suggest is just a shim that allows implementation of the interface on your existing code so that tests can be written against it.

Note that this fits very nicely with the "Strangler Application" technique mentioned in one of the other replies you received.

---

DWIM is Perl's answer to Gödel