Refactoring Fun

NogDog

So I whipped up something awhile back for a specialized task, creating one PHP class and a few lines of procedural code to call it. (It worked just fine, both functionally and performance-wise.) Now I need to do almost the same exact thing for another client. So I decided to do a bit of refactoring based on that original class, turning it into an abstract class that I can extend for the new task, plus likely future needs for the same thing for other clients. It's going along reasonably well, but every now and then I find myself wondering if, instead of modifying the original code, I should just start from scratch and do it all better, since (for now) I don't have to be in quite the hurry I was last time ("we really needed this done last week!")

I'm not really looking for answers here, just wondering if y'all ever go through the same angst and have any rules of thumb for when to modify versus when to start fresh.

laserlight

This reminds me of Joel Spolsky's Things You Should Never Do, Part I.

dalecosp

laserlight;11037553 wrote:
This reminds me of Joel Spolsky's Things You Should Never Do, Part I.

Might also tie in with http://xkcd.com/1205/

Bonesnap

I almost always start fresh. I might use my old code as a reference, but I find even after 6 months I look back at my code and say to myself, "what the hell was I thinking?".

dalecosp

Well, things are relative. I have a "production system" in the office that my supervisor uses everyday for a fairly important business function. It's been a over a year since conception and in production mode for about 11 months. It has some interesting AI-type functionality and has grown over time in terms of its capabilities (and the size of its codebase has expanded, too). Our customer relationship depends on this tool to a great extent (for some customers, that is). There's no way we could justify throwing it out to re-create it "better" at this point without causing significant down-time, and, even if we left the old code until a "switchover", there's no financial justification for redevelopment, even though, perhaps, I've "grown" in the last year.

So it depends to some extent what kind of project we're talking about ;-)

Derokorian

I think mostly its good to refactor. You can upgrade parts. And while a part may be 90% new, its a smaller releasable upgrade.

When creating a new project, any time I can pull existing code from something I've done I do it. Sometimes I pull it over, and rewrite it some to improve it. But it saves a lot of time to reuse as much as I can. I haven't written a file/class/whatever to connect to a database, runs queries, etc in a long time. I've slowly upgraded my standard classes over time, but mostly I just drop em in and use em.

At work, we have an old tool that is internal only but we can't let it go down. We've been rebuilding significant portions of it, sometimes not reusing any of that sections code again, but we would never do the whole tool at one. JMTC

dalecosp

Well, this is why modular/OOP practice is a Good Thing(tm) for us in the PHP world ... and the software world in general.

As you point out, modularity means that "modules" or code sections can be improved in a released product ... and that's true. My Friday AM routine involves checking the software I mentioned above and looking at usage patterns and PR's to see if any tweaking can occur. Just Friday I added a new subroutine to the key AI "module" and last week I altered the composition of a large object ... things that wouldn't be possible if he whole thing were a monolith.

But we could never just throw out the entire thing.