Major Project Refactoring

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I've recently been tasked with refactoring (rewriting, almost) an
ancient set of custom tools. They were originally written in good ol'
straight PHP, but there is a lot wrong with it. No includes (or
framework) so duplicate code everywhere; horrible architectural
decisions; horribly designed, completely non-normalized database;
dependency on register_globals, etc. In short, these tools were written
as somebody's "My First PHP Project" and I'm to bring them into some
semblance of maintainability.

I will be rewriting these tools into Zend Framework, but I'm not so
experienced with this sort of major undertaking. My question is: In what
order should I be rewriting this, taking into account both speed and
ease of development? Should I try to normalize the data first, and then
model the app around that? Write the app to reflect the current
database, then attempt normalization? Are there any general rules of
thumb for major refactoring efforts like this? Any suggestions would be

Also, if this question is too general for this group, I apologize and
would appreciate any nudges in the right direction :)

Re: Major Project Refactoring

Josh wrote:
Quoted text here. Click to load it

Same as when you're starting from scratch.  Design externals to the
program first.  This includes database, files, web pages, etc.  They
will affect your code.

Once you have the externals designed, you can design your scripts to do
what is needed.

Now you can define those resources (i.e. for your project, the database
and web pages) and then start coding your script.

Writing to the current database when you're going to redesign the
database anyway means you're writing code which will be discarded.
Don't do that (except for small test scripts and the like).  It wastes
time and adds additional bugs.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: Major Project Refactoring

Quoted text here. Click to load it

By the sounds of things, you probably need to start by documenting
what the system is intended to achieve. Without agreement on that,
should you be trying to replicate any bugs you find in the old system
in your new code?

Once you've done that, unless:
1) you need to replace parts of the system piecemeal
2) there's less than about 100 lines of PHP code'll probably save a lot of time and effort implementing a new
system based on the spec rather than refactoring what's already there.

(this is for the PHP code - its probably simpler to refactor the
existing HTML into templates, regardless of the size)


Site Timeline