Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re: OT: Rewrite or Refactor?

by GrandFather (Sage)
on Aug 27, 2006 at 05:14 UTC ( #569860=note: print w/replies, xml ) Need Help??

in reply to OT: Rewrite or Refactor?

Many things affect the most appropriate path. A further one you haven't mentioned is timescale. Generally refactoring can be accomplished more quickly than rewriting.

In your case it looks like a true rewrite is not possible in any case. Your only real decision is how deep to cut in the process of refactoring your existing code - you have to keep the system going.

Whatever you do, one of the first things you need is to implement a regression test system to ensure you don't introduce unexpected behaviour during alterations.

If you need to restructure your database, I'd be inclined to split the database back end off as soon as possible, wrap it up in a fairly abstract interface, then work on it as a seperate entity. Again, make sure you write test code to check things don't get broken along the way.

Actually, I'd imagine the whole process will turn into: Identify an area of code, write a test suite for it, put it behind an interface, work on it in stages until happy. To the extent that it is possible, putting stuff behind an interface is a pretty light weight operation and isolates clients of the code from changes behind the interface. It also makes for easy and comprehensive testing.

Note that there are two levels of testing involved here. High level testing of the integrated code - tests written against the code as it is at the moment, and tests written against focused sections of the code when those sections come under the spot light for refactoring.

So, your first task is to write a big test suite for the application, then identify sections of code that can be put behind interfaces. Make minimal changes to push each section behind an interface. Write tests against the interfaces. Then you have the freedom to rework each section independently of anything else that may be going on, and seperately from the live version of the application (because you are rewriting against the test suite, not in the context of the application).

DWIM is Perl's answer to Gödel

Replies are listed 'Best First'.
Re^2: OT: Rewrite or Refactor?
by badaiaqrandista (Pilgrim) on Aug 27, 2006 at 08:45 UTC

    Thanks for your reply.

    But how do you refactor the code architecture? I mean splitting one monolithic applications to become multiple applications that work together. Additionally, can I use the refactoring techniques to change my database structure from using multiple databases with the same schema to using one database?

    I admit that I haven't learned the refactoring techniques in depth. I just haven't heard of refactoring can work on such a high level as the software architecture.

    See this for my explanation about the architecture of my code.

    Thank you.


      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.

      DWIM is Perl's answer to Gödel

        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


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://569860]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (8)
As of 2020-10-19 15:26 GMT
Find Nodes?
    Voting Booth?
    My favourite web site is:

    Results (204 votes). Check out past polls.