Thoughts and Advice Concerning Large Refactoring Project

Ladies and Gentlemen,

The first step to recovery is admitting you have a problem right?

I learned to "program" for the family business.  The application
started 
on Delphi 1 with Paradox tables to help my father handle his business. 
Over the years my father received interest from colleagues in his low 
cost software so my father began to sell it here and there.

Over the years this compounded and the next think we know - offices, 
sales team, support staff, the works.

The problem is this: We did not learn anything about writing "good"
code 
adhering to good OO design.

Luckily I have seen the light and have begun studying the gang of four 
text, Refactoring by Folwer, K&R for ANSI C (I decided to learn a new 
language each year), and various other texts on design as well as some 
general C++ texts..including "Effective C++"

The problem is probably obvious - adding new features can be incredibly 
hard and introduce tons of bugs.  Fixing existing bugs can break/change 
other parts of the system as everything is as tightly coupled as you can 
get.  Code is hard to maintain (you can find 1000+ line procedures to 
accomplish calculations in one case!)

My first question is this:

Begin modeling and re-writing from the ground up while maintaining 
current code OR

Develop a good refactoring process as rewrites can be considered harmful?

Refactor current code as I also begin the process of researching some 
frameworks, patterns, etc and finally write/implement framework(s) then 
dump my UI on this new code?

e.g. write a function to create a new order rather than having the UI 
run code to generate a new order in 5 different places.

As far as refactoring - where to focus at the start?

I would THINK a good place to start on refactoring current code would be 
taking ALL non ui related code out of the ui to other units and write 
procedures/functions to manipulate my database stored business data. 
It's at that point I think to myself I could be better served ignoring 
that and start writing classes.

I'm totally torn, but having code that:

-Makes new code break old code
-Tied to a specific database (now NexusDB)
-Not portable, want a web version?  OUCH
-Hard to add features

is making a scenario where I work on code 12+ hours per day, make slow 
progress, and fall behind with the customers.

I must define a plan to improve this without spending ALL time 
refactoring/writing new code without fixing existing bugs and adding 
features.I must somehow do both.

Side note: After D1 we moved to D4, I quickly moved us to D7 and dropped 
the BDE for NexusDB.  I purchased Castalia to help me code quicker.  I'm 
one developer working on a project needing several that can't allocate 

On Sat, 12 Apr 2008 07:21:33 -0500, Richard Holland wrote:

<snip>

First off I would try and design some framework for the way I want
things to work. Wether you refactor in place or rewrite you are going
to need this before you can do much.
If you are going to refactor in place then you need to consider how
this will affect the existing code.

Usually I try and refactor in place, i.e., if I am working on a
feature then I figure out how to do it properly and I rewrite it. If I
can, I also migrate it to other places that use it.
Depending on the code you could do this a form at a time, or if it is
too complex then by function first.
I would also look at what you have and try and find ways to break it
up into chunks that you can rewrite without affecting other pieces.
The best advice I can give you is don't try and do too much at once.
Every time I do this I find that things don't work anymore and I have
to discipline myself not to.

A complete rewrite can require less time and be a lot easier. I have
often found it easier to start from scratch and with the original
source in another window and basically check off each feature the
original had as I re-implement it. The problem here is that you have
to dedicate a large chunk of time to it without any other expectations
(like customers), so it doesn't sound like this would work for you.

-- 
Marc Rohloff [TeamB]

"Richard Holland" <richard@drdispatch.com> wrote in message 
news:4800a94d$1@newsgroups.borland.com...
> My first question is this:
>
> Begin modeling and re-writing from the ground up while maintaining current

> code OR
>
> Develop a good refactoring process as rewrites can be considered harmful?
>
> Refactor current code as I also begin the process of researching some 
> frameworks, patterns, etc and finally write/implement framework(s) then 
> dump my UI on this new code?
>
> e.g. write a function to create a new order rather than having the UI run 
> code to generate a new order in 5 different places.


Definitely a tough place to be in. It's very tempting to begin writing a new 
version from scratch employing everything you've learned to this point. The 
problem with that is that is a big job that will take quite a bit of time, 
especially since you will still need to support the current product during 
that time.

Refactoring it piece by piece is much more manageable and less risky. 
Deciding on what to do first: you know the code and can judge those parts 
you consider to be most in need and have most benefit to you. In addition, 
take advantage of customer driven needs for changes or enhancements to 
improve the related code.

Your example of the redundant order creation is exactly the kind of thing to 
hit, only do not create a function to replace this, create a *class*. 
Initially the class will do this one function - create new orders, but then 
you have a place to gradually move the other related order functionality to 
as well. Not only will this allow you to isolate this code in one place, but 
can also move the database components for this portion out of the UI. These 
could be moved to a datamodule that is used by the new Order class 
(continuing to use data-aware controls - throwing these out amounts to a 
complete rewrite).

Gradually the application will become more manageable, though it'll never be 
nearly as optimal as it could be if designed differently from the start. But 
every bit is a gain and makes future work with it easier and less painful.

If you need to develop web access, then this is an opportunity to develop 
that project from scratch with properly separated concerns. For example, if 
you are going to use ASP.Net then create services using WCF that provide the 
business logic to the web app. Inside the WCF service, you can design the 
interaction between the business logic and data acess better.

Once you get a good part of this service working, it presents an opportunity 
to begin planning a new version of the existing application (if that will 
still be needed after substantial development of the web access). Since you 
will now already have the business and data layers written, it is a much 
more manageable task to build a new desktop UI that shares the same WCF 
services.

-- 
Wayne Niddery - TeamB (www.teamb.com)
Winwright, Inc. (www.winwright.ca) 

Richard Holland schreef:

> .....snip.....
> As far as refactoring - where to focus at the start?
> .....snip.....

I would start by investing in a good refactoring tool.

Sadly CodeFactor has gone, it was the best and it even beats Jetbrains 
Resharper for Visual Studio (c#) for refactoring features.

But there is still Modelmaker Tools, it has an unusual user interface 
but it has solid and extensive refactoring support.

Using a good tool will speed up the refactorung process immensely, 
allowing you to make changes that you wouldn't otherwise even consider 
for fear of breaking everything. Because a good refactoring tool doesn't 
make mistakes or typing errors it will also save you lots of debugging time.


Danny

I think what I'll do is:

a) Refactor into classes as I work on features/maintaining
b) Rewrite into new code as time permits by writing classes 
first..investigate OFP and MVP frameworks..take this process slow.  I 
can port my work in part a easily..and part a will more than likely find 
flaws in any object model I develop for the current application.

I'm evaluating ModelMaker, probably will buy that.  Castalia has good in 
editor refactoring.

I have trouble deciding what a class need do and not do - so starting 
from scratch could lead me to building a model that's not as good as it 
could be - being that I am new to all of this.