Re^3: Cleanup tools (auto HereDoc?)

It seems there may be no easy way to solve your problem from the looks of it. It seems quite a bit of refactoring is needed to incerase coherency and readability and also to root out and correct the mistakes. I don't think there are any modules, scripts or other code out there concocted to fix your problem, I don't think it'd be a wise idea to hold one's breath either. I hate sounding sarcastic but can i suggest a complete rewrite for a few reasons?

Compartmentatilization allows you to spread code out over more modules increasing maintainability and allowing you to prioritize loading and execution of code when and only when needed, thereby increasing the applications' effeciency and reducing the load on the hardware, a first step towards scalability.
A novel design could allow to to examine the drawbacks of the current approach, examine other better approaches, look into aspects that could be optmized and build a platform that will allow in the future, you or subsequent programmers to easily build other facilities into the current model and also allow you to easily attempt another code revision if the need arises (which usually does).
Refactoring allows you to gain first hand knowledge of the programmatic approad the previous programmer took, it allows you to take the best of both yours and his approaches to make something better. Hopefully, the code will be more modularized, more readable, easier to maintain and optmized at the end of the process.
It gives you the opportunity to see if any current technologies can be incorporated into the application to increase effeciency, scalability, etc. Things you have mentioned such as templating, Mason, mod_perl, memcached, etc, etc.
It gives you the opportunity to embark on a new project, to learn new code, techniques, etc. Something that your resume will be proud to bear.

It might sound unfair for someone like me totally unaware of the task ahead to easily say "go back to the drawing board"... Well, sometimes, a rewrite is necessary and this looks like one of those instances, horrid looking code, incorrect syntax, monolithic design -- all the essence of a programmer's nightmare. Think of it, how long can you continue struggling to make do with the current implementation? Rather than do what you originally set out to do i.e. clean-up/beautify the present code, you seek to gain a lot more advantages starting over again, this time learning from other's mistakes and taking enough preemption to write cleaner, more effecient, scalable and elegant code - with the technologies you feel will benefit it, etc. Not only will you sleep better at night, you'll do your company good.

perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er

Comment on Re^3: Cleanup tools (auto HereDoc?) Download Code

Replies are listed 'Best First'.
Re^4: Cleanup tools (auto HereDoc?) by garrison (Scribe) on Dec 03, 2006 at 05:51 UTC
I absolutely agree; unfortunately the customer did not want to start over from scratch and I'm disinclined to walk away from a project simply because it requires too many tedious (but billable) hours. I look at this as an opportunity to develop some new clever techniques.	[reply]
Re^5: Cleanup tools (auto HereDoc?) by f00li5h (Chaplain) on Dec 03, 2006 at 12:54 UTC
Well, billable hours are a good thing, but you have to ask yourself if you want to be trying to `polish a turd' for the next 6 months, or if it will be less painful and less smelly to just squeeze some of your own out? I suppose the trick is to make sure that the heavy refactoring that is needed won't impact on the customer. Either way they're going to have to pay for it to be re-written, if it's not all at once (as in re-doing it) it'll be re-re-rewritten as you take out the quotes in favour of heredocs, then the next guy replaces those with Templates, and the guy after him as to refactor something on another spot, to allow a new function to be added. I've been patching an unspeakable system for the past 9 months, and you know what? it's not far from where it was when I started, because of all the little odd off-by-one cases, and the wierd if-this-if-this-if-this conditions thrown about in it. If you want a well defined behavour and a nice set of clean interfaces, get a good unix programer (i'm sure you are a fine example of this, Firefly258, garrison et al) in and start again. Even if you refactor everything, to be perfectly readable and clear. you'll still be stuck with the initial design (if you believe they designed it) -- and how good can a design by these people be? slash rant. Not that I'm bitter about that `@_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;`	[reply] [d/l]
Re^5: Cleanup tools (auto HereDoc?) by Firefly258 (Beadle) on Dec 03, 2006 at 13:42 UTC
Politics and economics are a programmer's worst two adversaries, it's the case all over. They also indirectly and negatively affect ergonomics, a programmers friend. Like yin-and-yang, a balance must be struct between the two opposing forces for there to be happiness and harmony all around. Present a good solid case to the client, to make him wholly aware of the benefits a complete overhaul can bring over the long-run, the facts backed up by figures, the advantages and disadvantages of a new approach and the advantages and disadvantages of the existing approach. The number one reason to push for a revision is the side effects of poor legibility having a negative impact on the programmer effeciency (and other effeceincy indirectly) with the current code is simply unacceptable. Number two would be the long timeline between a proposal (for code modification, feature addition, etc) and the time of delivery of complete solution. Convincing a client that a certain radical approach is mutually benefecial is always a very hard feat, especially if they are worried about you leeching on to "billable hours" or are doubting your programmatic competence. A good, solid and sincere argument is necessary and it's clear you have one, you just need to compile the facts and figures that make the decision-making non-programmers understand the benefits they seek to gain. <--> `perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er`	[reply] [d/l]