[Dcphp-dev] Question & Comment: Cleaning Up a Codebase?

[Ray Paseur 703.346.0600]

Keith, you must be looking at some of my work!

Joel Spolsky has written extensively on the art and science, and I follow his occasional columns.  He quite correctly points out that it is easier to write code than to read it.  To a client, "easier" means "faster and less expensive."  Confronted with similar issues I have found it better to reorganize and recode, rather than trying to fix anything.  

How is it "better" you ask?  Thank you, I was hoping for that question.

Whenever I design and code a project, I plan to throw one away - call it release 0.9 or whatever, I will inevitably have overlooked something that will send me back to the drawing board for at least some of the project.  Compartmentalize like a pro!  You have the advantage that the throwaway version is already on your desk.

I would consider starting with the UI and documentation - if you get that right, the business logic often presents itself in an almost intuitive way.  

Thinking "MVC" seems to help, too.  I'm doing more of that sort of thinking lately.  One recent example I liked was a huge and complicated set of data base queries that produced elaborate reports.  The script interpreted all the user inputs, did all the queries, ordered the lists, set all the variables and finished everything dynamic before it spit out [HTML].  Except for headers and footers, the UI was all tagged and styled in tidy HTML and the variables were inserted with [?=NOTATION?].  Neat.  Easy to understand.  Easy to maintain.  Easy to extend.

I would probably avoid lifting long sections of code.  If there are classes or functions that are readily discernible and can be unit-tested, those might stay.  But for the most part, the time spent studying old flawed code seems, to me at least, less worthy than the time spent organizing the tasks and creating new code.

Finally, your situation is far from unique.  I am about to start on a similar project.  It was a real-estate closing data base, abandoned by the developers (they quit in frustration, but the annoyers are also out of the picture).  A concern the client most often voices is the anguish at having to throw away "all that good work" -- a legitimate concern to be sure, but not very goal oriented.  They have printouts of the DB tables but no definition of the field names, which are all things like "OPSTAGLUP" and "PTYFMRRS."  There are no records of which code has been tested.  When you add the fact that they have no user manuals or help files for the application... "all that good work" doesn't add up to much.  

That's my $0.02,
Ray

Keith Casey wrote:
> All,
> 
> I've been having this discussion quite a bit both on one of my open
> source projects, but also with a customer of mine and thought I'd get
> some input for the rest of the community...
> 
> What's the best way to go about cleaning up a codebase?
> 
> Assume that the code:
> *  was developed over multiple years (2, 3, 4+) by a handful of people
> of various skill levels; *  is mostly but not completely functional.
> There may be unused portions too;
> *  has UI elements strewn through business logic;
> *  has business logic strewn through UI elements (eg. validation via js 
> only);
> *  needs to have changes made to incorporate new fields, rules, business 
> flows;
> *  has nothing resembling Unit Testing.
> 
> So what is your hitlist?  Where are the first places you focus?  What
> are you red flags?  What makes you die a little inside?
> 
> kc
>